Project Management, do we need it?

[woohoo]

OK. So I wasn't prepared to write a book to explain to you every detail about the in's and outs of running a large project. You asked for some information about running a large project and I gave it to you. Whether you want to believe that I, as the PM, was instrumental in its successful delivery or merely some overhead who got in the way is up to you.



When I say things like "Recruit a team" ... that doesn't mean I was the only person doing the interviewing or deciding which skills were required. When I put together estimates I don't sit in a room by myself dreaming up numbers, managing risks is a group activity. All these things require input from others but as PM you are accountable for the project.

It's the difference between accountability and responsibility. The PM is accountable for the budget, the Dev-Lead is responsible for spending it correctly.

Part of the early stage estimates are "guesses" as you put it. There's no getting away from that. How else would you produce the estimate for a piece of work that you have not done, don't know what is required? You might say "Don't give an estimate". Well that is one option, but its actually not a very good option. You would find yourself looking for a new PM role if you tried that too often. Companies have budgets, PLC's have very strict budget processes and are often required to report budget figures to the market. As much as you might like to, you cannot say "I don't know how much this will cost, and I don't know how long it will take".

What most PM's do is to split the project into iterations ( "gates" ) and have an accurate estimate for the next phase, and "guesses" for the next phases. As you progress through the project, you refine your estimates, if you've built up the relationship with your stakeholders you can revise them up and down as you ( by "you" I mean the team ) learn more about what is required and eliminate uncertainty.

Phase 1 - establish the project
Phase 2 - Hire the team
Phase 3 - Decide on the options
Phase 4 - Choose an option
Phase 5 - "Design" your chosen option
Phase 6 - "Build" your chosen option
Phase 7 - Close


You'll notice that some of the phases overlap, you cannot hire the team without knowing exactly what you are going to do. But you cannot know what you are going to do, without hiring the team. So the reality is that you will be doing an activity from one phase in another ( doing some design as you decide on the options for example ). You might have some long-lead items that you need to order immediately because they'll take a year to be delivered. You might have some bits of work that are so speculative that the only way to do it is to get a clever techy and lock him in a room for 4 months whilst he comes up with a solution.

If you have enough distinct "deliverables", you might spin them out into "workstreams", effectively individual mini-projects

I didn't expand on the "Work" section because I figured that's the part of a project that you understand. I was trying to inform you about the other aspects of PMing that you are probably not aware of.

So back to your original question:

Do you need a PM to do all that? I think so. I don't see complex activity being coordinated across a company without someone driving it.

Please don't be defensive. You gave an answer which was detailed and must have took you some time. So, I read it and responded as best I could with the information you provided.

Early stage estimates are guesses. I don't know why you put this in quotes. You can't estimate with any degree of accuracy, it's a guess. This is bad for lots of reasons and you should not "guess". Once you pluck a deadline out of the air it's nearly always seen as a failure when this deadline is missed. Now, you could say well I inform the stakeholders that it's an estimate and likely to change but guess what, you now have a deadline. They will report back to their boss that x project should be finished by December. I've seen projects fail because of weak project managers that do this and then try to enforce their guessed timescales.

You talk about refining these estimates and it nearly never happens, often something is cut, like testing. Or features are pushed to another phase or the developers are asked to work harder/longer.

You didnt expand on the "Work" section, you talked about guessing estimates and putting a team together. Nothing I've read so far requires a project manager to lead the project. At most you could do with an admin person. The coordinating between teams could be done with suitable software and identifying lead developers so they can talk to each other without going through a PM as a filter.

[tomtomagain]

Please don't be defensive. You gave an answer which was detailed and must have took you some time. So, I read it and responded as best I could with the information you provided.

Early stage estimates are guesses. I don't know why you put this in quotes. You can't estimate with any degree of accuracy, it's a guess. This is bad for lots of reasons and you should not "guess". Once you pluck a deadline out of the air it's nearly always seen as a failure when this deadline is missed. Now, you could say well I inform the stakeholders that it's an estimate and likely to change but guess what, you now have a deadline. They will report back to their boss that x project should be finished by December. I've seen projects fail because of weak project managers that do this and then try to enforce their guessed timescales.

I am trying to get across that early stage estimates are often guesses. It's the PM's job to turn those ( with the help of others ) into more realistic estimates, based on reality. It's the PM's role to then present those estimates and get them accepted by the wider organisation.

Projects can fail because of weak PM's. But they can also fail because of weak Dev's or weak BA's.


I'll give you a scenario. You are playing the part of the "PM". Let's see how you would approach it.

===============================

You've been told that "The business" has let go of the lease of its building and given the landlord notice that it will leave. It is due to expire in 12 months time AND there is a no option to extend the date.

The problem is that there is an "IT Room" of around 100 physical servers ( although nobody actually knows how many ) supporting the business function housed in that building. The servers are on average 5 years old.

They need to be moved to a new location which isn't finished yet and to add a little spice to the problem, the business unit is located in West Africa.

You've got your first "Board Meeting" next week. At that meeting, the very very ( ruin-your-career-if-you-don't-get-it-right level of seniority ) manager will be there. He's exceptionally busy and will expect you to know: How much it will cost? How long will it take? Are you in control?

==================================

So .... what are you going to do next?

What's your first stage estimate going to be? Who are you going to hire? How are you going to tackle this project?

[SueEllen]

I understand SueEllen but you used admin tasks as an example. I'm trying to figure out when a PM is required, if at all. I'm asking myself is a PM a profession at all. Should PMs be leading software projects. It may seem I'm having a go but honestly just trying to understand.

Some of the projects I've worked on haven't had PMs because the position was not needed.

However the more complex projects I've worked on a PM has been there. If the PM is any good you realise how much tulip you, as a technical person, don't have to deal with.

I've worked on at least two projects with lying third parties that would have impacted delivery if the PM wasn't there to deal with them. On one of the projects there was no PM engaged until the lying third party had to be managed out without breaching the contract and another known third party engaged to do the work. This engaged PM and the other one worked across teams as there wasn't enough work for them to do on those projects.

Another more important job of a PM is that they are the fall-guy or fall-gal if the project screws up. Calling someone a manager means they can be the scapegoat and people don't have sympathy, but scapegoating an administrator never looks good as it is regarded as a low position.

[SimonMac]

We need project management, we don't necessarily need project managers

[woohoo]

Some of the projects I've worked on haven't had PMs because the position was not needed.

However the more complex projects I've worked on a PM has been there. If the PM is any good you realise how much tulip you, as a technical person, don't have to deal with.

I've worked on at least two projects with lying third parties that would have impacted delivery if the PM wasn't there to deal with them. On one of the projects there was no PM engaged until the lying third party had to be managed out without breaching the contract and another known third party engaged to do the work. This engaged PM and the other one worked across teams as there wasn't enough work for them to do on those projects.

Another more important job of a PM is that they are the fall-guy or fall-gal if the project screws up. Calling someone a manager means they can be the scapegoat and people don't have sympathy, but scapegoating an administrator never looks good as it is regarded as a low position.

I have no issues with taking responsibility for my work or projects, a fall guy is the worst reason I can think of for having a PM. In fact, it's a really bad reason because now you have a PM, who doesn't want to be scapegoat and is putting pressure on the team to meet timescale estimates he has guessed.

I think as others said there is project management work and a project manager. From what I can see there is some admin work and coordinating that could be done by a PM or administrator but I can't see a reason for a PM leading for example a software development project.

[greenlake]

We need project management, we don't necessarily need project managers

[woohoo]

We need project management, we don't necessarily need project managers

I think there is a need for an admin/coordinator - but a project manager leading software dev projects, not so sure.

[Bee]

Please don't be defensive. You gave an answer which was detailed and must have took you some time. So, I read it and responded as best I could with the information you provided.

Early stage estimates are guesses. I don't know why you put this in quotes. You can't estimate with any degree of accuracy, it's a guess. This is bad for lots of reasons and you should not "guess". Once you pluck a deadline out of the air it's nearly always seen as a failure when this deadline is missed. Now, you could say well I inform the stakeholders that it's an estimate and likely to change but guess what, you now have a deadline. They will report back to their boss that x project should be finished by December. I've seen projects fail because of weak project managers that do this and then try to enforce their guessed timescales.

You talk about refining these estimates and it nearly never happens, often something is cut, like testing. Or features are pushed to another phase or the developers are asked to work harder/longer.

You didnt expand on the "Work" section, you talked about guessing estimates and putting a team together. Nothing I've read so far requires a project manager to lead the project. At most you could do with an admin person. The coordinating between teams could be done with suitable software and identifying lead developers so they can talk to each other without going through a PM as a filter.

Guessing is not the correct word.
IT PMs have experience enough to know what time is needed to develop a new product or change it, in addition, the schedule is always confirmed with the development teams. The problem is there are always events that could put in danged the schedule and the PM needs to manage in order to decrease the impact on the next phase.

For example: If your dev team has an issue because you need something done from another team and if you or your team leader can't convince them, the PM needs to go there (which is bad) and tell them that needs to be done ASAP.

The PMs has a lot of issues to solve that are not visible to you and you think they are useless.

There is no software that can manage a project because there is always the human factor.

[Bee]

I think there is a need for an admin/coordinator - but a project manager leading software dev projects, not so sure.

An admin does admin stuff, like contracts, budget, etc. and not necessarily an IT person. For dev you need an IT PM with the experience in the business, or if it's a small project the dev. team leader can do some PM activities.

[woohoo]

Guessing is not the correct word.
IT PMs have experience enough to know what time is needed to develop a new product or change it, in addition, the schedule is always confirmed with the development teams. The problem is there are always events that could put in danged the schedule and the PM needs to manage in order to decrease the impact on the next phase.

For example: If your dev team has an issue because you need something done from another team and if you or your team leader can't convince them, the PM needs to go there (which is bad) and tell them that needs to be done ASAP.

The PMs has a lot of issues to solve that are not visible to you and you think they are useless.

There is no software that can manage a project because there is always the human factor.

I'm a developer with 20 years plus experience and I can tell you that you can't estimate how long a development project will take. You are you lucky if you can estimate how long a small task will take, if you have thousands of small tasks, you don't have a chance in hell.

IT PMs cause project failures from this kind of thinking. Even if all goes well, without the issues you talk about, you can't estimate how long something will take unless you have done the exact same task before and can remember how long it took. This does not happen often.