Mission Implementation

Consequently, as shown in Figure 1, I call this process pattern “The Three-legged Stool” pattern for development and transformation.  I will discuss each sub-process as a role with requirements.  Therefore, this is what I see as the needs or requirements for the process and the skills for the role.  In my next book, I will discuss more about how these can be done.

• Requirements Identification, Management, and Verification/Validation (see various other posts as well)
• Risk Management
• Configuration Management

There is a significant issue with designers and implementers, they attempt to create the “best” product ever and go into a never ending set of design cycles.  Like the Systems Engineering “analysis paralysis”, this burns budget and time without producing a deliverable for the customer.  One part of this problem is that the SMEs too often forget is that they are developing or transforming against as set of requirements (The “What’s Needed“).  In the hundreds of small, medium, and large efforts in which I’ve been involved, I would say that the overwhelming percentage of time, the SMEs never read the customer’s requirements because they understand the process, procedure, function, or method far better than the customer.  Therefore, they implement a product/system/service that does not do what the customer wants, but does do many functions that the customer does not want.  Then the defect management process takes over to rectify these two; which blows the budget and schedule entirely, while making the customer unhappy, to say the least. The second part of this problem is that each SME role is convinced that their role is key to the effort.  Consequently, they develop their portion to maximize its internal efficiency while completely neglecting the effectiveness of the product/system/service.  While I may be overstating this part somewhat, at least half the time, I’ve seen efforts where, security for example, attempts to create the equivalent of “write only memory”; the data on it can never be used because the memory cannot be read from.  This too, burns budget and schedule while adding no value.

Again, I will discuss solutions to this issue in the last two sections of this post.

• “The best of all leaders is the one who helps people so that, eventually, they don’t need him.
• Then comes the one they love and admire.
• Then comes the one they fear.
• The worst is the one who lets people push him around.

The first way is to give control of the effort to manager.  This is the “traditional” approach and the way most organization’s run development and transformation efforts .  The effort’s manager manages the customer’s programmatic requirements, (budget and schedule), so the manager plans out the effort including its schedule.  This project plan is based on “the requirements”, most often plan includes “requirements analysis”.

[Rant 1, sorry about this: My question has always been, “How is it possible to plan a project based on requirements when the first task is to analyze the requirements to determine the real requirements?”  AND, I have seen major efforts (hundreds of millions to billions) which had no real requirements identified…Huh?]

The Program or Project Manager tells the Systems Engineer and Developer/Implementer when each task is complete; because that’s when the time and or money for that task on the schedule is done, regardless of the quality of the work products from the task.  “Good” managers keep a “management reserve” in case things don’t go as planned.  Often, if nothing is going as planned, the manager’s knee jerk reaction is to “replan”; which means creating an inch-stone schedule.  I’ve seen and been involved in large efforts where the next level of detail would be to schedule “bathroom breaks”.  This method for resolution of “analysis paralysis” and “design the best” will almost inevitably cause cost and schedule overruns, unhappy customers, and defective products because the effort’s control function to control costs and schedules.

The Program Management Control Pattern
Figure 2 shows the Program Management Control Pattern.  The size of the elipse shows the percieved importance of each of the three roles.

To be able to “Control” the effort, the Program Manager requires many intermediate artifacts, schedules, budgets, and status reports, which use up the resources of the efforts and  are non-valued work products, the customer might look at these artifacts once during a PMR, PDR, CDR, or other “XDR” (Rant 2: Calling these review Program Management Reviews, instead of some type of Design Review”, Preliminary, Critical, etc., demonstrates the overwhelming perceived importance of the programmatic requirements by Program Managers.)  I submit that all of these intermediate artifacts are non-value added because 3 months after the effort is completed, the customer or anyone else will not look at any of them except if the customer is suing the the development or transformation organization over the poor quality of the product.  All of these management reviews require resources from the Developers/Implementers and the Systems Engineers.

One extreme example of this management review procedure was the procedures used in development of new aircraft for the US Air Force and Navy during the 1980s and 90s–sometimes facts are stranger than fantasy.  The DoD required some type of “Development Review” every 3 months.  Typically, these were week-long reviews with a large customer team descending on the aircraft’s Prime Contractor.  Program Management (perhaps, rightly) considered these of ultimate importance to keeping the contract and therefore wanted everyone ready.  Consequently, all hands on the effort stopped work 2 weeks prior to work on status reports and presentation rehearsals.  Then, after the “review” all hands would spend most of an additional week reviewing the customer’s feedback and trying to replan the effort to resolve issues and reduce risk.  If you add this up, the team was spending 1 month in every 3 on status reporting.  And I have been part of information technology efforts, in this day of instant access to everything on a project where essentially the same thing is happening.  Think about it, these aircraft programs spent one third of their budget, and lengthened the programs by 1/3 just for status for what?  Intermediate artifacts of no persistent value–Who looked at the presentations of the first Preliminary Design Review after the aircraft was put into operations?  [Rant 3: Did the American citizen get value for the investment or was this just another Program Management Entitlement Program funded by the DoD?]

Second, as shown in Figure 2, the Systems Engineering role is substantially reduced  in the perception of the Program Manager.  An example of this was brought home to me on a multi-billion program, when I asked the chief engineer where the requirements were stored, he quoted the Program’s Director as saying, “We don’t need no damn requirements, we’re too busy doing the work.”  This Director underlined this thinking; he kept hiring more program management, schedule planners, earned value analysts, and so on, while continuous reducing then eliminating the entire Systems Engineering team and leaving only a few System Architects.  He justified this by the need to increased control and cost reduction to meet his budget [Rant 4: and therefore to get his “management bonus”–no one ever heard of the Design or a System Engineering Bonus].  Actually, I’ve seen this strategy put into play on large (more than $20M) three programs with which I was associated and I’ve heard about it on several more within the organization I was work for and in other organizations, over the past 10 years.  

Another program that I worked on as the Lead Systems Engineer that had the same perception of the Systems Engineer (including the System Architect’s role within the Systems Engineering discipline/role).  It is an extreme example of all that can go wrong because of lack of Systems Engineering.  This effort was development of a portal capability for the organization.  It started with a that had 10 management personnel and myself.  They articulated a series of ill-thought-out capability statements, continued by defining a series products that had to be used (with no not identification of Customer System or IT Functional requirements), with a 6 weeks schedule, and ended with a  budget that was 50 percent of what even the most optimistic budgeteers could “guessitmate”.  They (the three or four levels of management represented at the meeting) charged me with the equivalent of “Making bricks without straw or mud in the dark”, that is, creating the portal.  Otherwise, my chances of getting on the Reduction In Force (RIF) list would be drastically increased.

Given that charge, I immediately contacted the software supplier and the development team members from two successful efforts within the organization to determine if there was any hope of the effort within the programmatic constraints to accomplish the task.  All three agreed, it could not be done in less than 6 months.  Faced with this overwhelming and documented evidence, they asked me what can be done.  The result was based on their “capability” statements, and “Requirements (?)” documents from the other two projects, I was able to cobble together a System Architecture Document (SAD) that these managers could point to as visible progress.  Additionally, I used a home grown risk tool to document risks as I bumped into them.  Additionally, I instituted a risk watch list report on a weekly basis, which all the managers ignored.

At this point one fiscal year ended and with the new year, I was able to have the whole, nationwide, team get together, in part, to get everyones requirements and design constraints.  Additionally, I presented an implementation plan for the capabilities I understood they needed.  This plan included segmenting the functions for an IOC build in May, followed by several additional several additional builds.  Since this management team was used to the waterfall development process, the rejected this with no consideration; they wanted it all by May 15th.  In turn, I gave them a plan for producing, more or less, an acceptable number of functions, and an associated risk report with a large number of high probability/catastrophic impact risks.  They accepted the plan.  The plan failed; here is an example of why.

One of the risks was getting the hardware for the staging and production systems in by March 15th.  I submitted the Bill of Materials (BOM) to the PM the first week in February.  The suppliers of the hardware that I recommended indicated that the hardware would be shipped within 7 days of the time the order was received.  When I handed the BOM to the PM, I also indicated the risk if we didn’t get the systems by March 15th.  On March 1st, I told him that we would have a day for day slippage in the schedule for every day we didn’t receive the hardware.  The long and the short of it was that I was called on the carpet for a wire brushing on July 28th when we had the program held up because of lack of hardware.  Since I could show the high-level manager that, in fact, I had reported the risk (then issue) week after week in the risk report she received, her ire finally turned on the PM, who felt he had the responsibility.

The net result of these and several other risks induced either by lack of requirements or lack of paying attention to risks resulted in a system that was ready for staging the following December.  Management took it upon themselves to roll the portal into production without the verification and validation testing.  The final result was a total failure of the effort due to management issues coming from near the top of the management pyramid.  Again, this was due to a complete lack of understanding of the role of Systems Engineering and Architecture.  In fact, this is a minor sample of the errors and issues–maybe I will write a post on this entire effort as an example of what not to do.

In fact the DoD has acknowledged the pattern shown in Figure 2 and countered it by creating System Engineering Technical Advisory (SETA) contracts.

The Utility of Program Management

None of the latter three types of leaders, as described by Lao Tzu, can perform perform this service to the team, the ones I call in my book, the Charismatic, the Dictator, or the Incompetent. In other words, the PM can’t say and act as if “The floggings will continue until morale improves”.

Instead, the PM must be a leader of the first type as described by Lao Tzu and as I called in my book as “the coach or conductor”.  And any team member can be that leader.  As a Lead Developer and as a Systems Engineer, I’ve run medium sized projects without a program manager and been highly successful–success in this case being measured by bringing the effort in under cost, ahead of schedule, while meeting or exceeding the customers requirements  Yet, on those none of the programs, for which I was the lead systems engineer and which had a program manager and who’s mission was to bring in the effort on time and within budget, was successful.  On the other hand, I’ve been on two programs where the PM listened with his/her ears rather than his/her month and both paid attention to the System Requirements; those efforts were highly successful.

The net of this is that a coaching/conducting PM can make a good team better, but cannot make a bad team good, while a PM in creating better projects plans, producing better and more frequent status reports, and creating and managing to more detailed schedules will always burn budget and push the schedule to the right.

1. If a development or transformation effort focuses on meeting the customer’s system requirements, the effort has a much better chance of success than if the focus is on meeting the programmatic requirements.
2. If the single fundamental assumption is changed from “All the requirements are known up front” to “Not all the requirements are known up front” the effort has the opportunity to be successful or much more successful by the only metric that counts, the customer is getting more of what he or she wants, and that increases customer satisfaction.
3. If the development or transformation effort can roll out small increments will increase the customer’s ROI for the product, system, or service.
4. Having a Program Manager, who’s only independent responsibility is managing resources be accountable for an effort is like having the CEO of an organization report to the CFO; you get cost efficient, but not effective products, systems, or services.  [Final Rant: I know good PMs have value, but if a team works, that is because the PM is a leader of the first type: a coach and conductor.] Having a Program Manager that understands the “three legged stool” pattern for development or transformation, and who executes to it will greatly enhance the chance for success of the effort.