A colleague recently gave me a copy of an article by Tom DeMarco, called “Software Engineering, An Idea Whose Time Has Come and Gone?” I later found an electronic copy here
Those of you who, like me, have been in Information Technology for a long time, will probably fondly remember Tom as one of the evangelists of measurement and control in software engineering, which appeared to me at the time to have its roots in Fredrick Taylor’s, “Principles of Scientific Management”. And even if you haven’t heard of Tom, you may have heard of his early book, “Controlling Software Projects: Management, Measurement, and Estimation” (Prentice Hall/Yourdon Press, 1982), or failing that, you may have heard his catch phrase, “You can’t control what you can’t measure,” or some variant thereof.
No, no, and no
Tom’s focus on measuring and controlling will probably strike a chord with many project managers, and it may also strike you as odd that someone who became famous advocating tight control, is now decrying it.
In his article he says,
“In my reflective mood, I’m wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no.”
As you read through the article he reveals that the cause of his discomfort is the implication that “metrics are good, more would be better, and most would be best.” He then goes on to say that software development is by nature somewhat imprecise, and therefore difficult to measure and control in a meaningful way.
Those of you who are familiar with PMBOK (a guide to the Project Management Body Of Knowledge) will know that the definition of a project (irrespective of the discipline – engineering, IT, or whatever) is:
“A project is a temporary endeavour undertaken to create a unique product, service or result.”
And right away you see what Tom is alluding to, it’s the very “uniqueness” of projects that make them slippery little devils, and the only thing you can predict with certainty is that you can’t predict anything with certainty.
Ok, up to this point I’m pretty much in agreement with him
Tom goes on to say that many projects have succeeded without much control (citing the creation of GoogleEarth and Wikipedia), and it’s around about here that it was MY turn to feel uncomfortable, as I could sense a “throwing out the baby with the bathwater’” approach, which we find soon afterwards where he says, “Can I really be saying that it’s OK to run projects without control or with relatively little control? Almost.”
There is a often quoted statistic that 75% of all IT projects fail, which to me implies that for each large project that succeeds without measurement and control, three or more will fail! If you “manage” one of the three-or-more failed ones, you will be reviled for failing to measure and control your project, and if you “manage” a successful one, it will not be attributed to your abilities as a project manager, for the same reasons.
So how does Tom suggest we run projects?
“So, how do you manage a project without controlling it? Well, you manage the people and control the time and money. You say to your team leads, for example, “I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product. Your job is to go about the project incrementally, adding pieces to the whole in the order of their relative value, and doing integration and documentation and acceptance testing incrementally as you go.”
The problems that it see with this approach are
“control the time and money”
But how on earth do you control time and money without measurement (and I thought we were doing away with controls)? The proper management of these resources requires the techniques of Earned Value Management, through which we can work out were we are, where we should be, were we will be in the future (if we continue at the current rate), and how to bring the project back on track.
“You say to your team leads, for example, “I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product.”
As a project manager you are responsible for change management, team building, morale and buy in, among many other things. The main tools in your PM toolbox include, painting the big picture/imparting the project vision, showing people where they fit in, their importance to the project – and providing information on what’s expected from them, and when, and how they are tracking against expectations. I believe that keeping important things secret from even the team leads, then springing a surprise deadline on them, will have the reverse affect and lead to missed deadlines, lower quality and considerable stress.
Most people work best when they have a deadline to aim for. Imagine athletes competing in a race and being instructed, “I’m not going to tell you the number of laps that you have to run. It’s somewhere between 2 and 50 – but I’ll rush out to signal when there’s one more lap to go! And there won’t even be a clock to look at” How many think these athletes would perform at their best under these conditions?
“Your job is to go about the project incrementally, adding pieces to the whole in the order of their relative value”
But what is meant by “their relative value”? You see the “value” of a piece of work usually means “its importance in relation to completing the project”, rather than some sort of monetary value. But the only way to truly know the importance of an activity or deliverable in relation to completing the project, is through some from of critical path methodology, which of course is based on measurement and control.
My comments may seem a little harsh, but I’m afraid of a return to the “bad old days’, when project “management” just meant doing “stuff” reactively and repeatedly, in the hope of a satisfactory outcome.
Keeping the baby
The PMBOK is not prescriptive, it tells you what you should know as a project manager, rather than a step by step guide. I.e. it is a framework, rather than a methodology. And you will read all through PMBOK that not all methods, tools and techniques are applicable to all projects, or should be applied to the same degree. This means that using your experience as a project manager, you need to decide the type and level of measurement and controls and so on, required for the successful completion of your project, and regularly review their use.
Jim Owens PMP