You are renowned as a great project manager in the construction industry. Now you have been asked to manage a large, green-field-site software development project. Do your undoubted construction industry PM skills equip you for your new challenge?

In a large construction project most of the heavyweight project management is associated with the physical construction phase: planning it and executing it. You are employing people with clearly defined skills which both they and you understand: foundation layers, steel erectors, bricklayers, plumbers, etc. There are, by and large, well known metrics for how long any given task will take. The number of tasks in the plan and the cost of each task can be estimated quite precisely. The project plan may be immensely complicated and require great expertise to put together but once the plan is built it can be "executed" in the virtual world and one can check that the plan hangs together. The plan for the Yas Viceroy Abu Dhabi Hotel which overlooks the Abu Dhabi F1 race circuit was so detailed they were even able to see where a crane would foul scaffolding at a certain stage of construction and revise the plan accordingly.

Of course, a construction project will only succeed if the physical construction phase starts out with an accurate and complete design of what has to be built. But one can rely on the architects to do that, and software can check the integrity of the design. The client must sign off the design before construction begins, but there are tools which give the client an excellent understanding of the thing that is to be built and their sign off can be an informed one. And it's pretty obvious to the client that if they want to change their mind when the building is half built it's going to cost them a lot of money.

Unfortunately, most of the characteristics above do not apply to software projects.

IT Software Development Projects

Software projects are different. Whereas in a construction project the project manager's main challenge comes in the planning and execution of the physical construction phase, in a software development project the main challenges come in the early stages. The project's fate will have been sealed long before the build phase starts.

In a software project it is very difficult for the client to specify what they want. Further, it is very difficult for the client to know whether the design produced by the system designers represents what they need. In software projects it is all too easy to enter the build phase with a design that is so poor that all the project management skills in the world cannot make the project succeed.

So why are large software projects so different and so difficult and so perilous and potentially reputation-destroying for PMs from, say, the construction industry? Every experienced software PM will have their own answer depending upon their own personal scar set, but the bear traps include the following.

Software Project Challenges

The Users. Suppose you're managing the development of a brand new software system that will handle a new way of administering state benefits. Who is going to tell you precisely what this new administrative process is? For example, what should the system do if the claimant has been in the country for less than 6 months, will reach state pension age within the first month of their claim, has a hearing disability, has one child under 5 and has previously made a false claim. Just finding someone who can specify the rules so comprehensively that the answer in this, or any other, set of circumstances is apparent, will be a huge challenge. And indeed maybe nobody has yet decided what should happen in those circumstances, so nobody can define the rules.

The project manager faces real difficulty in getting the client to understand just how much detail they must pin down before construction can begin, let alone getting them actually to do the work. And the client may, quite literally, not have the skills and resources available to specify precisely what they want. The project would thus appear to be impossible. Not that that stops un-blooded PMs charging on regardless.

Even if you do get the client to specify the process they want computerised ("The Requirements"), how do you know the resulting document is complete and correct? (And, by the way, if you don't know the answer to that question you certainly are not ready to manage a software development project.) Regrettably, in all too many projects, whatever the user has been able to specify, however inaccurate and incomplete, gets signed off and work continues with words like "we'll work out some of the details later..". ("We'd like you to build a big building please, really quite big. We'll work out the details of what that means during construction..." You wouldn't fall for that would you? But in the software world people do.)

Project Scope. In construction, if someone asks for a decorative turret on the building it's obvious to all that's a nice-to-have and the client manager or the PM can say "no, you're not having that". In software projects it is very easy for very junior people to generate requirements for nice-to-haves (which they will claim are mandatory), but much more difficult to spot them and much more difficult to say no to them. A software project can fairly easily be made two or three times as big as it needs to be by unnecessarily embellishing functions (gold plating), by including unnecessary functions and, even worse, by gold plating unnecessary functions.

Failure By Design

The Design. So the users have told you what should happen to that dodgy deaf immigrant pensioner's benefit claim. Now you must show the client what the bit of the system that handles that will look like. You show a screen layout and what data is entered and what checks will be done on the data (e.g. an age over 120 will be rejected). The client must now get their heads around this mass of detail and say yup, that's exactly what I want the system to do and I'm happy for it to look like that.

But who is the client? Are we just showing a flashy demo to a senior manager? Or are we forcing client personnel who (should) understand the detail, and client people who will actually use this system, to think through the detail? And whose job is it to make client personnel available for this work, and to ensure they do this work properly?

The danger is the client gets shown a succession of very pretty screen designs but are never forced to plough through the logic that will go on invisibly behind the facade. And they never discover (till testing or even implementation) that the logic sitting behind those pretty screens is incomplete and incorrect. Yet the client signs off a design document, the project continues (apparently on schedule) and nobody realises the project is holed below the water line.

Unlike construction, there are no clever tools which will tell you whether the design is coherent and complete. If you, the PM, don't know what you're doing, it may not be until system testing that you begin to realise what you have built is full of holes - even irredeemably so and the project has to be more or less started again. Or abandoned.

Change. If you want a window moved half way through construction of a building it's obvious it'll be expensive. The cost of changing something apparently minor half way through the programming stage of a software project can be equally large but much less obvious. Who is going to vet (and say 'no' to) the thousands of change requests that can sink a large software project? And if the requirements and design were poor, these changes may have to be done, one cannot say no to them, and even if the client is paying through the nose for the changes the chaos they can cause can still sink the project.

If the project falls apart because the client didn't do their job properly in the early stages of the project whose fault is that? It's your fault as project manager. It's your fault because you didn't make the client/users define what they wanted, and didn't make them apply their minds to ensuring the design represented what they actually needed. Your fault as project manager.

Bear Traps

The above are just a few of the bear traps. Any experienced large, green-field-site software development PM will be able to add quite a few deadly perils to the list.

Arguably all of the above challenges exist in construction industry projects. It's just that the scale and potential invisibility of them make them ten, a hundred times more difficult in large software projects.

Solutions?

One solution for the project manager making the transition to software development projects could be to hire a software development PM specialist to advise and assist him. But there are two cautions here.

Some software PMs style themselves as very experienced, but their experience is in maintenance. Making changes to systems - however large and complex those systems are - does not qualify one to manage green-field-site software projects. By analogy, it's rather like finding someone with years of experience doing DIY around their house and believing they have all the skills to manage the construction of a new supermarket from inception to completion.

And an even subtler trap: beware PMs who have managed small software development projects. The analogy here is someone who tells you he has built many sheds in his back garden over the years and on the basis of that experience can he have that supermarket construction job please. Small software projects are usually self-contained, have very few people saying what is required and can, to an extent, be built on a trial and error basis. This approach is even graced with fancy names like prototyping or extreme programming. Trial and error does not scale up to large projects: people who have only managed small, self-contained software projects know very little about managing large software projects.

Oh, and beware people with project management "qualifications". These can be obtained by attending a course lasting just a few days and tell you nothing about a person's ability to manage anything.

There is some help at hand. This Project Management Book sets out how some of the challenges, even the apparently impossible ones, might be overcome.

Project Management Articles:

Converting From Construction Project Management To Software Project Management

Do project management skills won in the construction industry equip a project manager to manage a green field site IT software development project?

Home Sitemap Contact Us Project Management Articles Project Management Book IT Project Management Course

Can Construction Industry Project Managers Manage Software Development Projects?