Project Management, do we need it?

[cojak]

And let's not forget the IT fairy who sprinkles fairy dust over forgotten passwords, old laptops, blank screens, frozen pages, and the other bits you don't notice because the dust is sprinkled before it get to you...

The PM manages the stakeholders so makes sure that the IT fairies know what's happening.

[woohoo]

That administrative person is called a PM. They then may have other people under them doing bits of the work but the buck stops with them.

However that's not their only job on the project.

Ok so rather than project manager we should have project administrator?

So you think the PM leads or should lead the project then?

[tomtomagain]

Can you give me some examples where a dedicated PM was required and what they did that necessitated a PM on these multi-million dollar projects?

Sure. I'll give you a walkthrough.

For a start you are making an assumption that a "Team" is in place at the start of the project.

I was assigned a project which required the purchase and installation of hardware, migration and upgrading of in-place systems, building interfaces to different systems and had an element of "bespoke development" attached.

However, when I was given the brief, the initial brief was "Our business Goal is X, we want you to achieve A, B & C"

The initial "brief" lasted about 20 minutes for a piece of work that would take nearly 3 years, cost upwards of $10M and require at least 100 different individuals. On "Day One" I was the only member of the team.

So the first set of tasks is to establish "governance", who's going to support you in your work ( you might not believe it but within companies, there are many different power structures who will actively set out to undermine each other ), who's going to pay for it ( again, the person asking isn't always the one with the money ), is it going to line up with the overall corporate strategy ( if the CEO is saying one thing, and the "customer" is asking for another, how are you going to deal with that? )

So in the very first phase, it's a lot of politics, building the initial "Project Plan".

NOTE : For those of you think that a "Project Plan" is an MS Project file or Excel spreadsheet ... you are wrong. A project "Plan" is a document or set of documents that give a high-level overview of how a project will be managed, budgeted and assessed. You are mixing up a "Project Schedule" with a "Plan".

At the end of your first phase you'll have a plan ( "How am I going to tackle this project" ), you'll be starting to figure out which skills you need to get going, you'll be figuring out the key dependencies and risks and which project activities you can off-load to the wider organisation. In my example, I was dependent on the larger "Infrastructure Department" to finish a new Data Centre build but of course I could pull in some of their experts for my hardware requirements ( I'm a software guy, don't know one end of network cable from the other ).

Of course, you are going to pushed very early on for a "number" - senior management want to know a few things. How much is it going to cost? When are you going to be finished? And most importantly Have you got it under control?

So you need to start a budget, ferreting around for similar examples of how much something might have cost in the past, information from your previous experiences, etc etc.

At some stage you'll have a Project Gate. The purpose of which is to discuss with your stakeholders the plan, seek their backing, and then ensure the funding is released. Depending on the maturity of the organisation this can be very onerous.


So you've got some money, got the backing of the board, everyone thinks you can do it! Now what?

Well you had better start building a team. Of course, you might not know all the skills you will need at this point, so you'll start recruiting into positions you are clear on. This recruiting can be from 3rd parties ( consultancies ), contractors or permies being seconded to you. Secondments are usually a pain ... not the people, but that fact that they are often not allowed to "leave their day job", so get distracted and called upon by their "real boss".

Once you get people on ... you've got to sell them the plan, refine it based on their experience, listen carefully to their views but not always accept them. If you've got someone external to the organisation they might need a few weeks to understand "How we do things around here". They might not like the way "Change Control" is done, but you aren't going to make much headway trying to re-write every corporate process ... you've got a project to do.

You might have contracts to negotiate, internal policies to follow and so forth. Depending on the organisation, this might mean dealing with a procurement department or doing it yourself.


So you've got a team and some money. Now what? A bit of detailed planning usually. What do we know? What do we know we don't know? Are we going to ask for more money now or in 6 months time? What are our key risks? What are our key dependencies?

Eventually, you start doing the work.

When the "work" is in full flow this is an unusual time for the PM. I always used to think, if I am busy, my team isn't and if my team is busy, I shouldn't be.

As a PM, if you've set the project up right, got the right people in, scoped it correctly, then when the actual "build" is happening you should be, not idle, but not hugely involved. You want to be stood back a bit from the crowd, scanning the horizon for danger, effectively dealing with issues as they arise, in a large project you get all sorts of problems, people dying, bits of the organisation being sold off, but you have to deal with it all. After all, just because your lead-dev's mother has got terminal cancer and he cannot focus on his job, doesn't mean your boss is going to forgive you if a critical part of a $10M project is going to be late.


... eventually, everything is done.

So you need to close the project, say goodbye to the people you've sweated with for the last few years, finalise the budget, learn your lessons and make sure its all accounted for .... so that when the next PM comes along with a vaguely similar project he has something on which to base his initial project plan on ...

[tomtomagain]

Do you think a PM should lead a software development project?

Like all good questions the answer is: It depends.

If the dev project is to do a 6 month enhancement to an existing system that already has a well-established software dev team, who have existing processes, have a good working relationship with themselves and the customer then probably not.

If its a project that is going to require multiple teams, covering different timezones and cultures, potentially lasting years then probably you will.

I don't think there is a right/wrong answer to it.

[SueEllen]

Ok so rather than project manager we should have project administrator?

I pointed out that isn't the only role they do.

However some large projects that span multiple teams also have an administrator or a co-ordinator who work under the PM.

[woohoo]

Sure. I'll give you a walkthrough.

For a start you are making an assumption that a "Team" is in place at the start of the project.

I was assigned a project which required the purchase and installation of hardware, migration and upgrading of in-place systems, building interfaces to different systems and had an element of "bespoke development" attached.

However, when I was given the brief, the initial brief was "Our business Goal is X, we want you to achieve A, B & C"

The initial "brief" lasted about 20 minutes for a piece of work that would take nearly 3 years, cost upwards of $10M and require at least 100 different individuals. On "Day One" I was the only member of the team.

So the first set of tasks is to establish "governance", who's going to support you in your work ( you might not believe it but within companies, there are many different power structures who will actively set out to undermine each other ), who's going to pay for it ( again, the person asking isn't always the one with the money ), is it going to line up with the overall corporate strategy ( if the CEO is saying one thing, and the "customer" is asking for another, how are you going to deal with that? )

So in the very first phase, it's a lot of politics, building the initial "Project Plan".

NOTE : For those of you think that a "Project Plan" is an MS Project file or Excel spreadsheet ... you are wrong. A project "Plan" is a document or set of documents that give a high-level overview of how a project will be managed, budgeted and assessed. You are mixing up a "Project Schedule" with a "Plan".

At the end of your first phase you'll have a plan ( "How am I going to tackle this project" ), you'll be starting to figure out which skills you need to get going, you'll be figuring out the key dependencies and risks and which project activities you can off-load to the wider organisation. In my example, I was dependent on the larger "Infrastructure Department" to finish a new Data Centre build but of course I could pull in some of their experts for my hardware requirements ( I'm a software guy, don't know one end of network cable from the other ).

Of course, you are going to pushed very early on for a "number" - senior management want to know a few things. How much is it going to cost? When are you going to be finished? And most importantly Have you got it under control?

So you need to start a budget, ferreting around for similar examples of how much something might have cost in the past, information from your previous experiences, etc etc.

At some stage you'll have a Project Gate. The purpose of which is to discuss with your stakeholders the plan, seek their backing, and then ensure the funding is released. Depending on the maturity of the organisation this can be very onerous.


So you've got some money, got the backing of the board, everyone thinks you can do it! Now what?

Well you had better start building a team. Of course, you might not know all the skills you will need at this point, so you'll start recruiting into positions you are clear on. This recruiting can be from 3rd parties ( consultancies ), contractors or permies being seconded to you. Secondments are usually a pain ... not the people, but that fact that they are often not allowed to "leave their day job", so get distracted and called upon by their "real boss".

Once you get people on ... you've got to sell them the plan, refine it based on their experience, listen carefully to their views but not always accept them. If you've got someone external to the organisation they might need a few weeks to understand "How we do things around here". They might not like the way "Change Control" is done, but you aren't going to make much headway trying to re-write every corporate process ... you've got a project to do.

You might have contracts to negotiate, internal policies to follow and so forth. Depending on the organisation, this might mean dealing with a procurement department or doing it yourself.


So you've got a team and some money. Now what? A bit of detailed planning usually. What do we know? What do we know we don't know? Are we going to ask for more money now or in 6 months time? What are our key risks? What are our key dependencies?

Eventually, you start doing the work.

When the "work" is in full flow this is an unusual time for the PM. I always used to think, if I am busy, my team isn't and if my team is busy, I shouldn't be.

As a PM, if you've set the project up right, got the right people in, scoped it correctly, then when the actual "build" is happening you should be, not idle, but not hugely involved. You want to be stood back a bit from the crowd, scanning the horizon for danger, effectively dealing with issues as they arise, in a large project you get all sorts of problems, people dying, bits of the organisation being sold off, but you have to deal with it all. After all, just because your lead-dev's mother has got terminal cancer and he cannot focus on his job, doesn't mean your boss is going to forgive you if a critical part of a $10M project is going to be late.


... eventually, everything is done.

So you need to close the project, say goodbye to the people you've sweated with for the last few years, finalise the budget, learn your lessons and make sure its all accounted for .... so that when the next PM comes along with a vaguely similar project he has something on which to base his initial project plan on ...

Thank you for your answer, interesting reading.

First off, just to get it out of the way, I've seen plenty of project plans that are MS Projects with the odd excel project plan. You are talking about a different type of project plan. So people are not wrong just talking about different things.

So, the first stage, you call it establishing "governance". I've seen this happen plenty of times, usually it's a champion of the product that sets this up and brings people together. Usually there are meetings where responsibilities etc are decided. Then the scope or the brief of the project is decided. I don't believe a project manager is required for this, usually they are brought in at this stage. The scope of the project is often developed within this group, sometimes including a PM.

So, second stage you pull a team or teams together. I would argue that a PM is not the best person to do this and a technical person could do this or at least advise the stakeholders. The person doing this should have experience of doing this and why should it be a PM.

Now, you mention that the senior management need a "number", how much is it going to cost, when will it be finished. So, this is wrong straight away. You can guess if you want, but no way in hell are you going to be able to give anything near accurate. So straight away as a PM you have done a really bad thing. You may have given a deadline for the project based on a few sheets of document you call a project plan. You have no idea at this stage. This is where projects fail, right here.

Now, your budget is just a guess, you can knock up hardware costs - until you find you need more and better hardware. You can estimate you need x individuals at x amount per day. But most of this is bulltulip. You are guessing.

Anyway, all this guess work does not require a PM to lead the project. Just someone to pull the information together and present mostly bulltulip.

Now, you need to build a team. Ok, I would say this is the best time to have a tech expert doing this, someone with experience of building teams. Not a PM, unless they are tech expect with experience of building teams.

So deciding keys risks etc, guess what the PM is going to ask the engineers, the developers etc to give them this information. But the PM won't understand it, so the engineers/devs etc do this bit. So, the devs/engineers are still going to spend time on this. Probably have to explain it several times until the PM can kind of explain it if anyone in the stakeholders groups asks about it.

So the "work" as you called it. You don't really get into this bit that much, just "your busy my team isnt". Most of the stuff above is fluff, guess work. Most of it can be done by a lead dev or engineer.

I'm sorry, but I'm not reading your reply going, yep I see the light now. Far from it. You actually make the mistake of giving time estimates and budgets on nothing but guess work. I've worked on 1, 2 year projects and you can't give accurate timescales, you just can't. And when you do give a deadline, it's deemed a failure if you don't meet it. So everyone rushes and produces crap and projects fail.

[woohoo]

I pointed out that isn't the only role they do.

However some large projects that span multiple teams also have an administrator or a co-ordinator who work under the PM.

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.

[tomtomagain]

I'm sorry, but I'm not reading your reply going, yep I see the light now. Far from it. You actually make the mistake of giving time estimates and budgets on nothing but guess work. I've worked on 1, 2 year projects and you can't give accurate timescales, you just can't. And when you do give a deadline, it's deemed a failure if you don't meet it. So everyone rushes and produces crap and projects fail.

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.

[darmstadt]

I think this thread pretty much proves that PMs are a waste of time. Look at the size of the replies justifying their need when a simple yes or no would have sufficed

[tomtomagain]

I think the main problem for a lot of PM's is they are put onto "projects" which aren't really projects and don't need a PM.

Not every project needs a PM, just like not every software project needs a developer.