I came across a nice blog post from DelancyPlace about the navigation powers of birds.
This bird was taken from Wale's to Venice Italy and released and found it's way home in 14 days. 930 miles, over mountains .
To be able to find their way home from an unfamiliar place, birds must carry a figurative map and compass in their brains.
The map tells them where they are, and the compass tells them which direction to fly, even when they are released with no frame of reference to their home loft.
Projects Are Not Birds
As project managers, what's our map and compass? How can we navigate from the start of the project to the end, even though we haven't been on this path before.
How can we find our way Home?
We have a map. It starts with a Capabilities Based Plan. The CBP states what Done looks like in units of measure meaningful to the decision makers. These units of measure are Measures of Effectiveness and Measures of Performance.
Measures of Effectiveness - are operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions.
These measures speak to our home and the attributes of the home. The map that gets us ti home is the Integrated Master Plan. This shows the increasing maturity of the deliverables that implement the Measures of Performance and those Performance items that enable the project to produce the needed capabilities that are effectively accomplish the mission or fulfill the business need.
This looks like a map for the increasing value delivery for an insurance company. The map shows the path or actually paths to home. Home is the ability to generate value from the exchange of money to develop the software.
The Death March project starts when we don't know what DONE looks like. Many of the agile approaches attempt to avoid this by exchanged not knowing for budget and time bounds. In the enterprise IT domain, those providing the money, usually have a need for all the features on a specific date to meet the business goal.
ICD-10 go live, new product launch enabled by new enrollment, Go Live of new ERP company wide, with incremental transition across divisions or sites. Maintenance support systems for new fielded products on or before products put into service - are examples of all features, on budget, on schedule.
The elicitation of the underlying technical and operational requirements has to be incremental of course, because knowing all the requirements upfront is just not possible. Even in the nth install of ERP at the nth plant, there will be new and undiscovered requirements.
It's knowing the needed Capabiliities of the system that are the foundation of project success.
Here is a top level view of how to capture and use Capabilities Based Planning in enterprise IT.
In a previous post on How to Assure Your Project Will Fail, the notion that the current project management processes are obsolete and the phrase of dealing with complexity on projects is a popular one in the software domain. By the way that notion is untested, unreviewed, and is missing comparable examples of it working outside the specific references in the orginal paper.
But here's the simplest approach to deal with project complexity...
Don't Let The Project Get Comnplex
Nice platitude, It's that simple and it's that hard.
Before the nashing of teeth is heard, here's a working example of not letting the project get complex.
So how is this possible? First let's make some assumptions:
Here's the steps to dealing with project complexity that have been shown to work in a variety of domains:
Let's pause here for a process check. If there is no narrative about what DONE looks like in units of measure meaningful to the decision makers (MOE, MOP, TPM, KPP) then the project participants have no way to recognize DONE other than when they run out of money and time.
This is the Yourdon definition of a Death March project. Many who use the term complexity and complex projects are actually speaking about death march projects. We're back to the fundamental problem - we let the project become complex because we don't pay attention to the processes needed to manage the project to keep it from becoming complex. Read Yourdon and the Making the Impossible Possible: Leading Extraordinary Performance - The Rocky Flats Story books to see examples of how to keep out of this condition.
When hear the notion that chaos is the basis of projects in the software world - run away as fast as you can. That is the formula for failure. When failure examples are presented in support of the notion that chaos reigns and there is no actual, verifiable, tangible, correctable Root Causes listed - run away as fast as you can. Those proposing that idea have not done their home work.
But the question of dealing with complexity on projects is still open. The Black Swans, that get misused in the project domain, since the term refers to the economics and finance domain through Taleb, may still be there. There are there because the project management process have choosed to ignore them, can't afford to seek them out, or don't have enough understanding to realize they are actually there.
So if Black Swans are the source of worry on projects, you're not finished with your project management planning, controlling, and corrective actions duties as a manager. Using project complexity as the excuse for project difficulties is easy. Any one can do that.
Taking corrective actions to eliminate all but the Unknowable uncertainties? Now that's much harder.
The needed capabilities for business or mission success starts with the Concept of Operations. With the ConOps we can identify the needed capabilities. Below is an actual project, with increasing capabilities for an insurance firm. The order of these delivered capabilities are defined by the business strategy and the Balanced Scorecard. Both define needed capabilities, the value stream map for producing business value or mission fulfillment and the order in which these capabilities should arrive to sustain the needed business benefits from the project. The by the way the mechanism for prioritizing features, which are much lower in the hierarchy of project elements that are commonly referred to in agile community. Features fulfill requirements, requirements implement capabilities.
Customer didn't buy features or requirements, they buy the capability to do something to improve their business.
A useful method of managing the project for delivering these capabilities is the Integrated Master Plan and Intetgrated Master Schedule.
These 5 questions need credible answers in units of measure meanigful to the decision makers.
What Does All This Mean?
With these top level questions, many approaches are available, not matter what the domain or technology. But in the end if we don't have answers the probability of success will be reduced.
Twas the Night Before Baseline
(With apologies to Clement Clarke Moore)
Twas the eve for the holidays,
And all through the shop,
Our consultants were working,
Would they ever get to stop?
All the CAMs had corrected
their IMSs with care,
With hopes that the IBR interviews
Would not be nightmares.
When all of a sudden
There arose such email chatter,
IMS updates were piling up,
So which ones would matter?
And what did I see
To my eye’s disbelief?
But even more IMS updates
In BoxNet motif!!
But jolly fat fingers
flew over keyboards,
And corrections were entered
Errors vanquished evermore!
Now CAs! Now WADs!
Now WPs! Now RAMS!
On CARs! On Baselines!
On Schedules! On CAMs!
To the TMT briefings,
To the top TMT Generals,
Now CAM away, CAM away, CAM away all!
Courtesy of Jay Charleston, CAM on a DTRA Anti-Virus Program. Our team was literally working the baseline submittal in late December for an IBR in mid January. Only the strong survive the 72 hours straight of re-baselining $350M a bio-pharma drug development program.
There are endless discussions about what went wrong with the Affordable Care Act web site development and deployment. It'll be hard to tell at this early point in the project assessment. But what is clear is this was mist likley a failure of project management.
Below is the acquisition life cycle for Business systems in the DOD, not that HHS is a DOD-style shop, but the paradigm of iterative and incremental development is in place. The release cycles shown here are way too long for something like the ACA Site. But to topology of the process is sound.
Looking at this process there is an obvious starting point. The Business Capability Definition. What is the resulting system supposed to do in terms of capabilities. Not the technical and operational requirements, but what business capabilities will the system provide to the stakeholder when it is in full operation? This is called Initial Operating Capability (IOC).
In our domain we start defining the capabilities using the Defense Acquisition Guide. Here is where Measures of Effectiveness (MoE) are defined. The Measure of Effectiveness is assigned to a capability. If we want a capability, how effective does it have to be? This measure is not a technical performance or a requirement. It is an effectiveness measure.
A MoE for a UAV program we work would be The UAV shall be transportable within a 3,000 mile radius via a C-17/C-141/C-5 package. From the MoE there is a Measure of Performance (MoP). For example weight is a MoP that enables the MoE to be fulfilled. Lower down are Technical Performance Measures (TPM). For example the weight of a Electro Optical / Infrared sensor platform must be under 55 pounds for the UAV to operate properly. It can't be too light or it would disrupt the center of gravity and can't be too heavy because the UAV would burn too much fuel to accomplish it's mission.
So for the ACA site, we'd need to know if there were MoE's, MoP's, TPM's defined that enable the Capabilities to be delivered. Here's the Performance Reference Model for federal IT.
Since the ACA site is pretty much all software, I'm going to suggest that this approach of using Capabilities Based Planning, MoE's, MoP's, TPM's has nothing to do with how the software is built. Either traditional or agile methods can be used. Agile is likely faster, but agile can only work in a domain like this if you know what DONE looks like in terms of MoE's, MoP's, and TPM's. This is a fixed launch date, fixed set of requirements guided by all the insurance regulations, and hopefully some not to exceed budget.
It is a common myth that government acquisition is waterfall and big design up front. DoD 5000.02 prescribes an iterative process designed to assess the viability of technologies while simultaneously refining user requirements. (pg 16 of 5000.02).
One starting question of the ACA Site would be - did they apply the iterative acquisition process in some form, no matter the fidelity of the iterations?
Here are some other fundamental questions as well:
If the answer to any of these is no or we don't know, go find out, get project managers who can do this. Otherwise the probability of project success is reduced. In fact look at the Probability of Program Success literature for further guidance.
The final question is did they have an Integrated Master Plan and Integrated Master Schedule for all the work as described in the Integrated Master Plan and Integrated Master Schedule Preparation and Use Guide? This paradigm has been shown to significantly increase the probability of success not matter the domain, context, development method, technology, or business process. It states in clear, concise, and unequivocal terms what DONE looks like at every point in the project in units of measure meaningful to the decision makers.
The final - and killer question is - did the project team ruthlessly manage the changes to the capabilities? This is suspect is the root cause of the failure. Late changes to complex projects are the kiss of death.
As repeated often here...
Don't do stupid things on purpose
So Now What?
We have to wait to see what the Root Cause Analysis (RCA) shows for the failure of the project. But I'd conjecture the program management processes found in large DoD or NASA programs where not applied in any meaningful way. The site is not larger compared to most of the programs we work ($400M is small), but the processes used to manage those programs can be scaled down with ease. The Principles are the same. The Practices are scalable and the Processes scalable as well.
There is a post related to the #NoEstimates discussion titled, Introducing Deliberate Discovery. It's one of those interesting topics that doesn't use the same words across most domains.
The word Plan in our domain is a Strategy for the successful completion of a program. The Integrated Master Plan (IMP) says what steps need to be taken to increase the maturity of the deliverables over the life cycle of the project. Here's the elements of project success at a minimum. The IMP/IMS is one. But risk, packages of work, the delievrables, Measures of Performance, budget spreads for the work, and other lower level artifacts are used as well.
There's a post on a Deltek implementation partner site about applying Earned Value. It has some good advice, but the premise of the starting point needs to be addressed.
Before going on to suggest things to do on a project using EVM, it's best to have one of those don't do stupid things on purpose discussions. If the customer or potential customer is doing stupid things on purpose, it's important to stop those first, before attempting to make any other improvements. Once that is done, the core paradigm of Earned Value Management is very simple and obvious ...
Turning the Subjective into the Objective
This phrase is not mine, it is a colleague's who said it while we were walking down the hallway of a client site, who is introducing EVM to a $1.9B weapons program that has never had EVM before, but is now being mandated to do so by Congress!!!
So Here's the Introduction to What Not To Do and the Simple Fix
Let's start with a picture of where to start. The are 32 Guidelines in ANSI-748-C. 11 are needed for he success of any project, in any domain. If you aren't doing these 11 in some way, the probability of success for your project is low. This is the case of all project management and product development processes, These are like the 5 Immutable Principles - they have to be there in some way. Here's the 32 from ANSI-748-C and the 11 are colored and listed below.
So Let's See How the 11 Can Address Each Of These Issues?
Here's their list of reasons why Earned Value Management is not readily adopted by contractors.
So What Does All This Mean?
It means applying the 11 Guidelines shown above to your program is the same as being a credible program manager. If you're not doing these 11, you're probably not doing your job as a Program Manager on an EVM program. Think about that. You've been assigned to look after $20,000,000.00 of the governments money. Would you actually use some the phrases above when asked why you're doing a poor job of managing the program? Not for long I suspect.
One Final Comment
Earned Value Management is one of several enabling technologies to turn the subjective into the objective. But it is only a necessary condition for success. It is far from a sufficient condition for success. You need an Integrated Performance Measurement Baseline with these elements
Chris Chapman has a nice post addressing some of the issues of #NoEstimates. This tries to explain why we should consider the approach of developing software without an estimate of the duration or cost. Let's look at these concepts in light of a software development project that is spending someone else's money. Commercial money or government money.
Hopefully these questions are not a surprise to anyone writing software using other people's money. So let's see if I can work through the concepts that Chris has presented, without completly pissing off the angry voices of #NE. Here's Chris's direct quotes.
So Now For the Punch Line
Let's assume we work for a customer that has a governance process where budgeting for projects is part of everyday life. With the processes described above from Chris's #NE post we can easily answer: how much budget will we need to allocate for this project? And once you've got the budget authorized and allocated to the project, when can we expect to start returning value to those who funded the project?
This is one of those WTF result. The #NE paradigm, as described in the post, is standard incremental development, on fine grained boundaries, with sufficient reference class forecasting calibration to establish a basis of future estimates. Just like you'd find in any IMP/IMS, rolling wave, work package, Earned Value Management 0/100 Earned Value Technique (EVT) program we work for DOD, DOE, or NASA. WTF, This is how we do things. We calibrate the capacity for work - within each software intensive reference class, e.g. Avionics, Life Support, Communications, Rendezvous and Dock - then use those calibrated capacities, using a model, to construct the estimates for our future.
You can't have a forecast to completion - the estimate of ETC or EAC - without knowing the underlying capacity for work (assuming no rework). Get this measurement and you're all set to forecast the future completion data and cost (assuming constant dollars) IFF you know the number of items in the queue. These items are of course the Stories in the queue, if you follow Vasco's advice. They can also be Function Points, sysML features, Interfaces, even SLOC from memory constrained flight avionics Handel-C FPGAs
In the End
This has been a tortuous journey, exacerbated by some who poorly defined the very purpose using more platitudes than I've encounter in some time. One of these is the common platitude of simple minded agile that deliver early and often. Which is only the case when the receiver of the software - from the queue - can actually accept the software, AND the software doesn't age while waiting for it to be consumed. While some myfind this strange, in complex, interconnected system like those found in ERP, embedded processes, SW/HW integrated system, this is common. The order of assembly is critical.
A much better approach, using exactly the same processes, is to deliver as planned. The plan states the need date for the software and the order of the software. The whole notion of priorities of features is the basis of Capabilities Based Planning and systems engineering processes that are mandated by our procurement process.
But I can just here a few voices talking If this is working for you just move on. Which of course is complete BS, since every project, especially software projects, on the planet is troubled in some way. So it doesn't work for us, or for anyone. No one has a lock on the solution. Especially those without a sufficient understand that what they are saying is nearly identical to existing processes.
What has been will be again, what has been done will be done again; there is nothing new under the sun. - Ecclesiastes 1:9
TechWell is an agile site that has been around for awhile. There is recent post on Agile and Federal Government. While the concepts of the post are useful, there are some issue with the underlying processes that need clarification.
Earned Value Does NOT Define the Development Process
The post suggests EVM requires Waterfall. First the development process defined in the picture on Page 2, is not allowed. Not to say there aren't people out there using it. While the Integrated Defense Acquisition, Technology, and Logistics Life Cycle Management System may appear overwhelmingly complex, it is the basis for all complex acquisition processes. It defines an itertaive and incremental process for buying weapons systems. Increasing maturity of the deliverables is defined at each Program Event.
But in an EVM program which is defined by several Federal Acquisition Regulations and the Defense Supplement, DI-MGMT-81866 calls out an Integrated Master Schedule. Along with is the DOD acquisition Life Cycle process where incremental maturity of the delivered products are defined in the Integrated Master Plan. The Guide of the IMP/IMS shows how to build a credible Plan and Schedule for a program.
We have to remember EV is only required on programs greater than $20M and a validated system on programs greater than $50M. DOE requires EV on programs greater than $5M and HHS has similar requirements. But $20M of software development is a BIG program. And you'd better have something better than Scrum looking after the expenditure of $20,000,000 of the government's money.
Waterfall Replaced By Rolling Waves
The second picture suggests that Agile provides an iterative solution. But in fact Rolling Wave development, defined in the acquisition guides does the same. RW's can certainly be a substitute for iterations.
But a better solution is to move the Agile Iteration down to the Work Package level. A Work Package in the Earned Value Management paradigm, is a self contained "package of work" that produces a tangible outcome that fulfills the Criteria needed to complete the Accomplishments that define the increasing maturity of the deliverables for a specific Program Event. Look at the IMP/IMS Preparation and Use Guide for how to do this.
So Here We are Again
I'm speaking again at EVM World in Naples FL, on integrating Agile with EV. Notice a critical phrase, Agile integrated with EV. Not the other way around. If you have a project less than $20M and are currently using Agile, there is no need for EVM. Don't do it, assuming you've actually got control the program. EV can add value for sure, but it's not mandated.
Here's the previous briefing on integrating agile into EV - EV+Agile=Success. The current one is slightly better and will be available May 26th, 2013.
So What's the Point
While there is growing enthusiasm for integrating agile into government programs, the acquisition community has not caught up. The agileist suggesting how to do things need to understand more of how the acquisition community thinks about managing the government's money. Open ended development may be the rage in commercial business (probably not), not if we are be to good stewards of the public's money more than just agile needs to be in place.
This notion of agile on governemtn prorgams is itself an emerging topic, that needs much more discussion before true value can be created. There are examples of success in the AirForce, DOE, and NASA. I've worked some of those programs and written about them in conference proceedings. But to simply apply agile in the absence of the acquisiton communities participation is going to lead to disappointment. Agile is needed, but so are the controls in place in the FAR/DFARS processes.
This is from an article about the application of Bayesian Statistics to a civil suit in the UK over the source of a building fire.
The idea that you can assign probabilities to events that have already occurred, but where we are ignorant of the result, forms the basis for the Bayesian view of probability. Put very broadly, the 'classical' view of probability is in terms of genuine unpredictability about future events, popularly known as 'chance' or 'aleatory uncertainty'.
The Bayesian interpretation allows probability also to be used to express our uncertainty due to our ignorance, known as 'epistemic uncertainty', and popularly expressed as betting odds. Of course there are all gradations, from pure chance (think radioactive decay) to processes assumed to be pure chance (lottery draws), to future events whose odds depend on a mixture of genuine unpredictability and ignorance of the facts (whether Oscar Pistorius will be convicted of murder), to pure epistemic uncertainty (whether Oscar Pistorius knowingly shot his girlfriend).
When we build probabilistic models of project performance - cost, schedule, and technical - we assume we understand the underlying statistical processes that drive these probabilistic generating functions. These are the aleatory uncertainties in duration, cost, and performance. We define the Probability Density Function in the Monte Carlo Simulator. Then we apply that to the network of work activities (the Integrated Master Schedule), to produce confidence outcomes for completing on or before a planned date and at or below a planned cost. This is all fine and dandy. But we really don't know the underlying drivers that create coupling, correlation, and cross correlations between the work activities, cost, and technical performance. These can be model by discovering the drivers in the network.
For the Epistemic uncertainties we need another modeling tool. The current tools don't actually use Bayesian statistics, rather they use Monte Carlo Simulation and treat the Probability of an Event as an aleatory process integrated with the other PDF's, ranges, and their shapes (Kurtosis and Skew).
We're missing the tools needed to construct a credible epistemic model of how the program works. Using the Integrated Master Schedule (IMS) as the topology for work, the probabilistic behaviours of the work elements at each node - cost, schedule, and technical performance compliance of the products - and the coupling and cohesion of the nodes. With this information - assuming it is credible, which is a HUGE assumption - we could model the behaviour of the program and ask what if questions.
The domain we work in is unique in some ways compared to the general roles of a Project Manager. First is the "management" of the project or program is done by a specific set of people. The Program Manager and the Control Account Managers. The "program controls" function provides oversight and insight to those people.
There are specific roles on the PP&C (Program Planning and Controls) side of the program. Here are the questions we ask when interviewing someone for that role:
Planning1. Integrated Master Plan
2. Integrated Master Schedule
Earned Value Management
3. Control Account Plan
4. Work Package
5. Earned Value Execution, in you experience ...
Monitoring and Control
6. Performance Measures
7. Performance Reporting
8. Duration Estimating
9. Technical and Programmatic Risk Management
10. Critical Path Analysis
11. Building the IMS
12. Microsoft Project Demonstration
These and similar question will bring out the level of experience on the PP&C side of the project. These of course are not related to the other aspects of "managing" the project. But when someone says, "I've got experience managing projects," this is one place to start to see if "providing performance visibility" to the project has been one of those experiences.
There is a popular myth - mostly by those Agile Management 3.0 thought leaders who don't play or even know much about team sports involving balls, grass - about "emergent" behavior. The myth is that the "rules" of the game and the boundaries of the field are the governing guidance in the game of Football.
The Michigan coach in the picture to the left is looking at his playbook. The playbook defines what plays can be, or are going to be, used during the game.
The playbook has to follow the rules of the game. That's the role of the referees and field judges. If the play is not in the playbook, it is not going to be used during this game. There may be more plays available to the team than are in the playbook for today's game, but they're not going to be used.
So here's the lesson for Project Management.
Where is your Playbook? And If you have a Playbook, are those Plays going to increase your chances of winning?
Don't have a playbook?, then it's going to be an ugly day. Have a playbook but don't execute the plays properly?, it's going to be an ugly day. Execute the proper plays in the proper sequence, your chances of winning will improve. No guarantee's, just be improved.
The Playbook for a project is the Integrated Master Plan. The application of the plays, like American Football, depends on the emerging situation that resulted from the last play. Not the score on the score board. That's the Integrated Master Schedule.
Does this mean the Master Plan doesn't change during the game or during the project? Of course not, that would nonsense. But you better have a really good reason for changing the plan. In football and baseball, that's actually a strategy - to get the other team to change their plan. To go off the playbook and try doing something that they haven't practiced well enough to properly execute. To disrupt the flow of play.
How about changes in the Master Schedule during the game or during the project? Happens all the time. Here's a thought to put to work in ball games as well as projects.
Planning is not “plan and forget” but an ongoing dynamic activity that peers into the future for indications as to where a solution may emerge and treat the plan as a complex situation, adapting to an emerging solution.
If you have a Plan B, you should have given thought to the possible Plan B's, before you execute Plan B. Otherwise your Plan B may be just what your opponent wants you to do - decrease your probability of success.
This idea comes from a colleague Mike Dwyer, IT Program Manager, used with permission.
So why the notion that a football team - or a project - that self-organizes within the boundaries of the playing field and the rules as they are laid down by the football association? Without the understanding of the Playbook, with most times the plays being called in by the coach. Can't say. Maybe because those notions come from observers of football, not players of football.
In the past NAVAIR had a CD with all the SETR Program Event Checklists. Each had an Excel spread sheet that you filled out to determine if you were ready for the Event and a supporting document that describes all the details of the Event, both entry and exit criteria. The picture above has the link to the current spread sheets.
This approach to the Integrated Master Plan spelled out explicitly what "done" looked and there was no way to skip around the check list and call the work "done," without passing all the items with a GREEN. I've requested from NAVAIR the latest, but looks like it has been expanded to be DOD level now.
This paradigm is at the heart of describing what "done" looks like in units of measure for both the buyer and the seller. Measures of Effectiveness for the buyer and Measures of Performance for the seller.
Got an invitation to a Webinar today on scaling Agile to larger teams. This is a very important topic in our domain, since we work software intensive programs that are distributed around the campus and across the country.
Here's the introduction...
Why do the Agile thought leader say this crap. There is no project on the planet that can define all the requirements up front. It's actually prohibited in the DoD 5000.02 procurement life cycle. Detailing everything to be done is utter nonsense. Design the complete architecture, are you f!@#'in nuts. No credible architect would do this. Parcel out work to component teams based on architecture and specification. Does this speaker actually work on complex integrated systems, say manned space flight, or ERP integration.
The bio says Howard worked in aerospace, he should know better than to talk this way. The 5000.02 and IMP/IMS paradigms have been in place long enough to stop saying waterfall. I know some commercial places do this, but they are out of touch with reality. This red herring approach is not only annoying, it does a disservice to those working on complex software systems.
Doctor, doctor, it hurts when I do this, than stop doing that you idiot
Ok enough, how about some rational concepts about scaling. What Howard describes in his paper is similar to the iterative and incremental procurement life cycle of DoD systems.We always start with capabilties, not requirements, no details, not architecture. The agile thought leaders might be well served to take a look at this Capabilities Based Planning paradigm.
The level of detail and commitment for these process varies depending on the domain. It may be some of these are not appropriate for the problem at hand. But you do need to ask if this is the case, before discarding them.
With these capabilties defined to some level of fidelity, the development teams can start to apply good agile processes.
These questions get answered in a Value Stream Map that describes how the software system is going to evolve over time, what capabilities the customer is going to receive as a function and time and then the customer can assign the Business Value to that capability.
Here's a picture of a real project doing that.
With this Program Architecure the system architecture, the teams allocated to producing the capabilities, and the defined Business Value can all be used to start developing the Use Cases, Stories, Operational Concepts and any other things youthink you need to execute a Scrum process.
In exactly the way Howard describes it in the picture titled Think Feature Partitions, not Components.
But notice the process step above in the first Bullet Define Capabilities as Operational Concepts and then the bullet Partion system capabilities into classes of service within operational scanarios. Well that's standard DoDS 5000.02 Systems Engineering.
What Howard is describing - and hopefully not taking credit as an orginal idea - is mandated DoD Systems Engineering. It's just good program management practice.
Once you get into the article good stuff starts to flow, but those Red Herrings in the tag line a turn off for us in the world of complex systems development and intergation of software intensive products and services.
But there are some Gaps in Howard's Picture
The critical understanding here - or missing understanding - is that Software development in large complex projects is NOT the repalcement for Program Management and Systems Engineering.
If all your participants are sitting in the same room with the customer, then those processes are implicit in the air. Once you move away from the single face-to-face team you muust have wrapper processes to keep everyone moving in the same direction.
H. L. Mencken: “For every complex problem there is a solution that is simple, neat and wrong.”
In the previous post, the new IPMR DID instructs us to integrate cost, schedule, and technical performance.Here's some more advice.
Now the bigger question. Where is the similar advice for IT projects. Agile starts down this road, but needs a broader capabilities statement. PMBOK based PM doesn't have much to say if anything around this. Home grown PM processes are usually simple and obvious check lists.
The Afterburners has a seminar titled High Resolution. Their tag line is
Without high resolution, an organization can not align its tactics and strategic plan. High resolution details ensure the organization can execute and provide results that align with the expectations of those that developed the strategic plan.
In the project and program management domain, this means several things, that are many time missing. Missing means the probability of success is reduced. Missing means the project participants have to return to just doing work. Here's what's missing - the the Afterburners guys provide in ways that are rarely found in the PM world. They spoke at a Rocky Mountain PMI Symposium and I attended a training session. It's not for everyone, but if you want a clear and concise approach to getting things done, they're the one.
Here's where to take their quote:
This all comes together in the Integrated Master Plan and Integrated Master Schedule.