On the other hand, there are some people out there who really have the knowledge and the will to get things done, and that’s Project Management for them, it’s not about methodologies, it’s simply about getting the work done (to satisfy all stakeholders) in any possible way. That’s real Project Management.

The objection voiced in this post is not fundamentally to Project Management, as it claims. The general objection is merely to having to be asked a few questions…

(1) umm, how long do you suppose it might take?

(2) when do you think it might get done?

(3) uuhh, mind giving me a ballpark estimate as to the cost?

and, the dreaded…

(4) how far along do you suppose you are?

These types of questions annoy 14 year old boys, and of course, they annoy many programmers.

Thank god for the increasing numbers of people with these skills, some of whom actually have a sense of what it means to work as a team.

The fact that languages change and new, inexperienced people enter the industry and forcing loss of knowledge, gets interpreted by “coal-face” coders as that what they are doing is original.

To take an example from left-field, if you were writing a paper on economic theory, would you research the web and paraphrase someone else’s work, or would you set about creating a whole “new” economic theory that matched what you thought others expected? Only in software do we assume that we can do it better than anyone else before, and thereby ignore most of what has gone before.

I have been writing software since 1987 (prior if you include university and school). The problem is that software developers see the world as you do – it’s all about code.

However, after decades of analysis and exhaustive studies around the world, code “writing” is shown to vary as a percentage of total project time in development projects as being between a little under 15% to a little over 18% of entire project effort. It is up to the project manager to understand this and other metrics, and to ensure that software “writers” are not given the opportunity to present their estimates out of context from the programme of work. Otherwise, their audience anticipates that a developers estimate is all there is and of course then blame developers for delays when their original estimates only accounted for < 20% of the project.

Also, even the coding can be reasonably accurately estimated (within +/- 10%) by experienced estimators off the back of design specifications – just like engineers can estimate total cost of the back of engineering drawings.

To my mind, the physical world with real people and real relationships, politics, changing environmental factors, project governance, etc is significantly more complex than software development – both of which I do.

I mean, do you know it can take days to negotiate a sub-contractor’s price – and you can tell whether it will take an hour or a week until you finish the process. Yet, physical projects sometimes deal with thousands of sub contractors. And that is just one very minor aspect of a large engineering project. I’ll bet the negotiators would love to deal with something as predictable as code.

Maybe my comments make a difference, maybe not; but the sooner the software industry pushes project management across all aspects of itself, the sooner our lives will be less about insufficient time and more about predictable outcomes for specific efforts put in.

Cheers,
Have a good Christmas.

A silly comparison – real world, physical structures that have been build before can certainly be planned down to the hour.

Writing software is just that: writing. Many things can go wrong along the way, starting with end users not disclosing their actual process to create the report, data or whatever.. then you find out LATER after giving a pessimistic estimate of your coding time.

apples vs Oranges Mr. maxwell.

I found your blog because I just wrote about this. Its interesting, but has aspects of truth and misguided PMs.

- Josh
MIT Technical, Boston

Time and cost are, of course, related as more time is generally increased cost (unless you drastically cut resources).

But features is a very important factor and something the customer/user truly controls. Features is generally inversely proportional to cost and time. When faced with longer cost/time than desired the customer/user will often decide some features are not as essential as originally thought.

In this way I try and have the customer control the software project. Frequent meetings and discussing the current state of these three factors generally results in more customer/user satisfaction. Which generally results in more satisfaction for me.

Talon

I think in terms of ‘technical, schedule, and cost’, where ‘cost’ is shorthand for all resources.

This formulation parallels the classic offer that a good project manager can make to the sponsor: “Fast, Good, and Cheap – pick any two!”.