Over the next few weeks I'll publish excerpts from my talk at the 2012 Microsoft Project Conference. This week: Beware the Flowchart.
Here's my starting point. I believe the Project users/project managers can add business value to their organizations in compelling and sometimes surprising ways. Here for example is how one might look at that seemingly harmless artifact of business process visualization, the flowchart. A project manager brings with him or her an appreciation of the inescapable fact that things get done over time, and looping actions in flowcharts sadly don't result in time travel. Let me illustrate.
Here is a highly, highly simplified flowchart of a complex endeavor:
The items in the flowchart should be very familiar to you--they're a generic representations of a project's broad phases. It's certainly not the only such representation one could draw, but it's fine for our purposes here.
Now I can start with a flowchart like this and with a little customization and more detail, I could more or less illustrate most projects that come across my desk. I could do so in a way that would more or less make sense to my projects' sponsors, resources and other stakeholders.
Here's where my project manager focus comes in. First, let me rotate the flowchart to its side, and introduce that tasty magic sauce of project management, a timeline (TIP: click image to see a larger view):
See what I did there? I sequenced the broad phases of the project against a specific timeline. What I can't represent in this view of the flowchart though is the loop-back route out of the "Complete?" decision point. Let's see how this plays out.
Let's give this project the benefit of the doubt and say that it was initiated, planned and executed as planned--right up to the "Complete?" decision point. This point might be, for example, an integration phase of work where the components of the project come together and we find out if they work together as planned. I've drawn a progress bar through my timeline to date:
Let's say that the answer to that question, "Complete?" turns out to be...No! There are many, many reasons why this might be so. The specifics don't matter here but the higher-order bit here is this--what's the consequence of not being complete at this point in time? In the original flowchart, the consequence was a graceful loop back up to the Execution task. But what happens in the real world? I'm referring here to the real world we inhabit where time (unlike flowcharts) does not loop backwards--time travels only in one direction. Here's the result, which we call...rework! It looks like this:
The project has grown in scope (compared to baseline)--we've added rework to address whatever caused our initial answer of "Complete?" to be negative, and we've incurred an additional task to again determine if we are now, at last, done.
Sadly, we run through these additional tasks (or rework), and again determine that yet more rework is required:
We may complete the rework to everyone's satisfaction, or more likely we (or the customer) will run out of patience or money. We'll declare success (such as it is) and release the product:
Ouch, that's quite a lot of additional duration (and we can assume cost) that was added to the project just due to that seemingly harmless "Complete?" loop in the original flowchart. And by the way, you can be sure the ship party will be cancelled due to the sad ending of the project.
This has been of course a grossly simplified telling of the story, but it's based on a kernel of truth. The traditional flowchart format, with its failure to address work over time, can lead to disastrous simplifications of the true nature (and especially risks) of the work. I hope this blog post will help you work through similar problems when you discover them.