I’ve seen it more times than I can remember; I’ve read it twice as much. Projects that fall into one of the three categories:

  • Incomplete / Requirements not Met
  • Over Budget
  • Committed Time for Completion Missed

Actually, now that I think about it, I’ve seen many projects fall into all three categories. The outcome varies by project, of course. If I break this down to its simplest form: I could say that forgetting my yogurt at the grocery store, yet leaving with a tab that is twice as large as I’d anticipated, and still missing the crucial time to begin cooking a timed dish, was a failed project that pretty much hit the three categories. In this situation, the project (getting groceries for a dinner that evening) wasn’t so dire that bad things will happen for the foreseeable future. Nonetheless, there was an impact…I was hungrier for a longer period of time than I’d wanted, and I spent more money than I anticipated.

For larger projects, or those that are initiated to achieve much bigger outcomes, the impacts can lead to outcomes that last far longer. I think it’s safe to say that a project to replace an aging payroll system stands to have a bit more impact than my grocery example noted above. But, there are commonalities between the two “projects” that bring projects down to a very standard framework.

  1. Each project has a desired outcome. This outcome is generally not single threaded in nature, that is, it’s rarely as simple as “get groceries” or “replace the payroll system.” So, breaking this into a multi-threaded outcome, it’s pretty easy to accept that each project has a lot of things that must be completed in order to achieve the overall goal for each. This is the scope.
  2. Each project has a date, or time of day, by which the project must be completed. In the case of my groceries, I needed to ensure I had completed the project by the time I was ready to start preparing my meal. For a payroll system, the date is most likely driven by many facets–some very complex. For example, at the turn of the 21st century, there was a phenomenon known as the “Y2K bugs.” I won’t delve into the details of what that translated to at the time. Suffice to say, billions of dollars were spent to fix, or replace, systems so that they could handle dates beyond 12/31/1999. This is the time in which a project must be completed. (Defined here as the time the project was initiated to the time it had to be completed.)
  3. Each project has tangible things that are required to finish successfully. I needed a person (me) to go to the grocery store. Since it’s not within walking distance, I needed a mode of transportation. While at the store, I needed to have an ability to find and purchase each ingredient that was necessary for my meal. For the payroll project, the needs are much more complex–more than I have the time or desire to state here. Subject matter experts, programmers, equipment, quality assurance people, etc. These resources are critical. Try to build a house without resources. It won’t happen.
  4. I had a budget for my grocery run. No doubt, the payroll system had a budget as well. If one (or more) of the three items noted above isn’t managed well, the costs exceed what was originally anticipated. If the scope changes, you have to do more work. More work, takes more resources (people/materials), and almost always, more time. This is money, cold hard cash. Of the basics for project management, this one is the most controversial for me. There was once a time when this wasn’t considered a “leg of the stool” for project management. It was presumed (and rightly, I argue), that money correlated directly back into resources. If more people are needed, than it stands to reason that it will cost more. An argument would be that the profitability of a project does not correlate to resources, and therefore, does indeed tie only to money. My argument to that argument is that a required level of profitability is captured as a part of the scope; if proper planning was done estimating the cost of the resources, and the scope addressed the necessary aspects for what it took to reach profitability, a separate “leg” of the stool for money was superfluous at worst, redundant at best.

So, using this framework, let’s take a look at what went awry with my grocery “project.”

  1. Scope – It appears that the scope was indeed set. I knew what I needed in order to create my meal that night. It wouldn’t appear that the scope was a problem.
  2. Time – It was clear what time at which my grocery run must be completed. I had a specific recipe that required a period of time that was necessary to have a finished meal.
  3. Resources – Like scope and time, the resources for my project were available. I was available, I had a functioning mode of transportation to get to/from the grocery store, and the store had the items I needed for my recipe.
  4. Money – Well, I had sufficient money to get the items I needed. I’d anticipated the costs beforehand, and had a means by which I could secure the resources I needed for successful completion.

So what went wrong?! Simply, the project wasn’t managed well. Although I knew everything necessary to successfully complete my project, inclusive of constraints, I still failed to meet the original scope.

The fact that I arrived home without all of what I needed shows one of two things: I either didn’t create a list of items, and therefore forgot all that I needed -or- I had the list and it wasn’t used. So, despite having a completely defined project, I still failed to manage the details. Consequently, I didn’t achieve the goal.

Project management is really an under realized hero. Consider a movie. From start to finish, it is a project–and a complex one at that. But when the credits roll, it’s not the project managers that are at the front of the list (if at all–honestly, I do not remember seeing any, but I don’t remember waiting). It’s generally resources (actors), followed by other “important” resources (lighting technicians, etc.). While it’s true that the actors are what people want to see, the movie wouldn’t be possible without some level of project management.

The same carries through to other projects. I worked on a very large development project that was extremely complex. The project finished on time, within the budget, and met the complete scope as defined. (Though, there were many attempts to “modify” the scope throughout.) When completed, a congratulatory memo was sent thanking the business unit representatives, programmers, infrastructure team, etc. Notably absent was the PMO (Program Management Office). I was on the infrastructure team, so I wasn’t slighted. But I did recognize the value the PMO provided throughout the project. And, most importantly, I knew that the project would have been a disaster without their oversight and guidance. Look at the list of resources to whom the memo was sent. Now, ask yourself what the odds are that a programmer would have any interest in coordinating activities with the infrastructure team. Or, what the odds are that the business unit representative would have the knowledge necessary to see project-affecting risks that were technical in nature. Not likely.

As I’ve progressed through my career, I’ve learned to appreciate project management in all aspects of my work life, and honestly, for some of my personal aspect. (e.g., As a pilot, it’s pretty obvious that every flight is a project–where to go, how to get there, resources needed, time period required, overall cost). Professionally, as I noted at the start of this entry, I’ve seen a lot of projects that fail. In all of these scenarios, a competent level of project management could have prevented them–and in most cases, rescued them. Unfortunately, not every sees project management as an unsung hero.