You Want IT When?

Is formal project management necessary to successfully deliver a software project?  The short answer to that is no.  Many successful software products have been launched without any project plans or schedules, at least not in the traditional sense.  When I first started in this field, project plans were not the norm, but that was when programs fit in a device with less than one megabyte of memory. 

History

Things were different 20 years ago.  When I purchased my first 512 Megabyte hard drive, I thought that it was all I would ever need. Now I have over a terabyte of hard drive capacity, and it’s not enough.  However, one thing has changed: it’s the data that’s driving the secondary storage requirement today and not the requirement to install programs.

The software development teams were much smaller then too.  While I have anecdotal knowledge, a typical project team size was five or less software engineers in my experience. Some were bigger but not much bigger, and still fewer were even much bigger.

Software engineers had more responsibility: they created the functional requirements, created the designs, create the code, made the builds, created the test harnesses, created the test designs, executed the tests, packaged the software for release, wrote the user documentation, and supported the product.  This was the practice even in some large companies.

Present

Things have changed significantly.  Most applications today cannot execute in less than one megabyte of RAM.  The hard drive capacity common in the early 1990’s couldn’t support the install of Windows Vista.  The size of the teams has grown.  It’s difficult for me to say what a typical team size is today, but teams I have managed over the past  five years ranged from twenty team members to a couple of hundred, and instead of team members being collocated in a single office, the team members are located across the globe.  

Less Formalism

It’s possible to manage a team successfully without formal project management practices when the team and application are small, much like the typical project in the late 80’s and early 90’s.   If you think about it, how much logic could you create for a machine with a memory capacity of 640K and no virtual memory?   And if you were building embedded applications back then, the onboard memory capacity was typically significantly less. 

Teams were smaller because we were building less sophisticated applications, and we were building less sophisticated applications because the technology was less capable than today.  With smaller teams and smaller deliveries, a good manager could easily and successfully lead the delivery of an application without many of the formal project management practices. 

More Formalism

Today, project deliveries are much bigger than they were 20 years ago.  Team members are spread across the globe.  Applications are more complicated today.  For example, web applications are typically multi-tiered and distributed across machines; in addition, many different software technologies are used in one application: C#, SQL, HTML, .NET, AJAX, etc… Consequently, more formalism is required to manage these projects to deliver them successfully because the teams have gotten larger and more complex.

Why Plan

However, some professionals in the industry would still ask why should we manage with a formal plan?  Too much changes, and any plan is shortly stale after it is written.  Some would also say that it’s impossible to estimate a project successfully as estimates are always inaccurate, so any schedule is going to be wrong from the start.  However, these are precisely the reason to formalize planning.  

One of the key benefits of a project schedule is that it’s a tool, the only tool, to manage project change successfully.  The process of project management is essentially the process of creating a schedule, executing the plan, testing your estimating assumptions, and taking corrective actions when you learn that your estimating assumptions are incorrect. 

Without having that baseline view, there is no way to know that your project will not deliver on its commitments until it’s too late to take corrective actions.  A skilled manager is able to deliver on time even though the initial schedule proves to be inaccurate because they use the schedule as an effective tool for managing change.

If the schedule that you end your project with is identical to the schedule that you started with, then you were not managing your project.  Successful project management is the process of managing change and taking corrective actions when change is identified.  Change is reflected in the project schedule with either new tasks or original tasks reprioritized or ending earlier or later than scheduled. The inevitability of change is a reason to plan.  Consider these quotes.

“No battle plan ever survives contact with the enemy.”
–Field Marshall Helmuth Carl Bernard von Moltke

 
In preparing for battle I have always found that plans are useless, but planning is indispensable.”
– Dwight Eisenhower

Both quotes affirm that change is inevitable and that nothing goes as planned, but Eisenhower’s quote says something further: “planning is indispensable.”  He’s confirming that the process of project management is the source of its power.  The power is identifying what went wrong and taking corrective action.   It’s identifying what when right or better than expected and redeploying those resources to the highest priority needs.  You can’t do that if you don’t have a baseline plan, and you can’t take corrective action if you never assess how you are progressing to the plan.   Planning is indispensable.

Summary

Project management is a continuous process of planning, executing, measuring, and re-planning.  It’s the process of meeting your commitments in spite of all the change and obstacles along the way.   It’s a tool for managing change and complexity.  It’s hard, and because some aren’t successful with it or don’t do it well, it doesn’t mean that project management is not valuable.  Sometimes we blame poor execution on the process or the tools, but too often in software management it’s the skill that is at fault.  The difference between the 300 Avg. batter in baseball and the 200 Avg. batter isn’t the bat, the ball, or the rules of the game, it’s the skill of the batter.  If we can focus on the skill rather than debate the need for the tools, in this case project management, we can progress the practice of software management to higher levels because skills can be improved with practice and education.

References

A number of months ago I stumbled on the blog Herding Cats authored by Glen B. Alleman.  He authors a great blog on project management, and I consider him an expert in the practice of Project Management.  Many of his essays are provocative and insightful.  I highly recommend that you visit his site regularly for his perspectives on project management.  Here’s a link to one of his essays: Simple Conditions for Project Success.