We should manage both our critical project path and our critical project thread.  The critical thread is what I call the subset of the organization that has the processes that are key to the success of our project or product.  Monitor and manage these key processes with our project management tools and our overall project is more stable and predictable.

Let’s look at a couple of examples:

Fighting A War In Central Europe

We were developing software for the joint militaries in Central Europe.  We were a small cog in the grand scheme of things.  The grand scheme of things is of course how we would fight a war in Central Europe.  To be ready to fight a war we had to practice.  We called these military exercises and command post exercises. Our organization supplied critical command and control software used in these periodic military exercises.

We were terrible at delivering software on time that worked well.  In fact, most people used a manual system rather than using our software.  They didn’t need the headache of buggy software just as we were trying to send commands to fend off the enemy hoards coming over the pass.  We finally took multiple actions to improve our software delivery process.

One such action I instituted was a “90 day” policy.  The policy was simple. No software change or enhancement request that came to us would take less than 90 days to complete and turn over to the customer.  Yes, if you wanted to correct a typo on the display, you would see the fix in the next 90 day release point.  My boss at first objected to this approach. We had recently started to release software that was not late and buggy and everyone had begun to get excited about software based capabilities again.  We were seeing an influx, a spike, in requests for software changes and enhancements.  It was starting to get crazy, so I instituted the policy.  Luckily, my boss – a German Lieutenant Colonel in the Luftwaffe – soon liked the hard line policy.  It helped to bring order to the chaos.  He did not like chaos. (But also compare the last example in Thriving On Defective Software – Project Management Tools That Work.)

We soon earned a reputation of consistently delivering normal updates along with innovative new capabilities on time and with good quality (for many reasons, not just the 90 day policy).  The military organizations throughout Central Europe came to realize that if they needed a new capability for the next exercise they had to let us know 90 days before they wanted to start training with it.  They knew we would deliver on time and that it would work.  These other organizations started to line up their own process to feed our own.  Organizations that did not have a need for software, but otherwise had activities to perform to prepare for the exercise, also would align themselves with our 90 day deadline.  We became the definitive, well defined, key process thread in the whole exercise process.  Before this, the whole process was pretty mushy as to definite dates, except of course for the actual exercise start date.

This software process had become a critical thread through the entire exercise process.  It was no where near the most important activity.  It was not on the critical path as we had manual ways of doing what needed to be done with software.  Yet, by ensuring the software process went well, the rest of the exercise process worked that much better.  By ensuring this key thread was doing what we needed, the entire effort was steered in the right direction and at the right tempo.

Software Is Why We Are Always Late

We were always three to four months late with our new products.  Always.  Completely new products, changing everything including the software architecture and technology, would be six to nine months later than we had promised.

There were at least a dozen disciplines involved in producing the product: software, mechanical, electrical, supply, marketing, integration, test, quality, accessories, manufacturing,  etc..  Software had the dubious reputation for being the reason we were late.  It always seemed that the final defects were in the software.  At that time, the physical appearance of the product was what generally sold it.  The software was needed, and we had lots of software features, but it was really the product look and feel that caused it to jump off the shelf.  The rest just had to work well enough.  But, software was the discipline that pulled everyone else down.

Since software was the culprit, it gave us the opportunity to get the schedule right.  We used the fact that we were the cause of the problem to insist on a schedule that allowed the software a chance to be ready on time (see how at Get The Schedule Right – Project Management Tools That Work).  The software process thread reached throughout the entire product development life-cycle.  So we ended up, to get the software out on time, specifying the entire duration of the product development.  In a sense, we were telling the other disciplines how much time they would get.  The funny part is that no one objected.  They didn’t object because we were helping them get the time they needed to get their stuff right.  You see, a lot of the noise about software was a cover for the other disciplines.  They too had issues, not nearly as many as software, and needed that same period of time to get theirs all right.  When we finally got software on the right track and good quality, the problems in the other disciplines started to stand out prominently.  Some disciplines were not too happy about this!  In one case, where we did deliver the entire product on time, the final major issue turned out to be hardware related.  That just didn’t happen in the past.  It had always been software.

By getting the software discipline worked out, it gave everyone what they needed.  It was not necessary to project manage every process in detail.  The software development process is often one of those critical process threads.  If we can get the software process going well, the other disciplines such as supply, electrical, mechanical, marketing, etc., can align and even heal themselves.

Sometimes we just need to bring order to one key process thread to stabilize and enhance the overall project.

What are the key process threads in your project or organization?