Project Management, do we need it?

[SueEllen]

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.

So you happily to take responsibility for 10 teams of varied sizes in 4 countries using different technologies to produce one product?

Oh and the PM doesn't estimate the timescales in the projects I've worked on for years, s/he delegates that to someone senior in each team.

They then add the times up and may hassle you if your estimate for your bit is larger than they want. However you can refuse to change it especially if you are wise enough to consult other senior people in the team and department before giving the estimate.

Btw Another job of a PM is to resolve conflicts and sack people/third parties. Remember HR doesn't get their hands dirty and in some cultures if you aren't a manager you don't get respect.

[billybiro]

How does it work if there are 3 plus dev teams helping to develop one product? Who helps to co-ordinate them all especially when people in the teams disagree?

Certainly not the PM, or any other "manager" type. Disagreement between dev. teams will almost certainly be of a highly technical nature, such as the specific architecture to use to implement some part of the system. The very last person you want "resolving" such disagreements is the PM, who almost certainly i) is not very technical, or at least not as technical as the developers and ii) probably has the least amount of information about the problem.

There's a famous story about a high level manager at Microsoft who absolutely refused to adjudicate when two or more developers on the many teams that he managed got into disagreements and all for the reasons I state above. He would force the developers to continue the disagreement and resolve it themselves based upon merit. Of course, this assumes you've got developers who can back down in an argument if they're shown a genuinely better way, but of course, that's a whole other story.

[woohoo]

So you happily to take responsibility for 10 teams of varied sizes in 4 countries using different technologies to produce one product?

Oh and the PM doesn't estimate the timescales in the projects I've worked on for years, s/he delegates that to someone senior in each team.

They then add the times up and may hassle you if your estimate for your bit is larger than they want. However you can refuse to change it especially if you are wise enough to consult other senior people in the team and department before giving the estimate.

Btw Another job of a PM is to resolve conflicts and sack people/third parties. Remember HR doesn't get their hands dirty and in some cultures if you aren't a manager you don't get respect.

First off, how does a PM take responsibility for 10 teams in 4 countries. They don't, the conversation goes something like, why did product X fail and the PM replies team a in Manchester buggered up for this reason, blah blah. They don't sit in a meeting a go I hold my hands up it was my mismanagement that caused our product to fail.

PM may collect estimates but you can't estimate a software development project to any degree of accuracy. It's just a guess. Worse by estimating you are forcing the developers to work to these timescales and they may rush. They certainly won't stop and say, gosh thinking about it I can think of way of making this much better, just need to spend a couple more weeks on it. So the quality of the product can also suffer even if it's delivered within your estimate.

The team lead can resolve conflicts, in fact they are probably in a much better place to do this if its a technical conflict.

[billybiro]

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?

I understand where you're coming from, and I also know that most (if not all) "enterprise" projects are run just as you describe, but to bring it back to the point of the article linked to by the OP, none of what I've quoted above is actually delivering value to the business.

For the "kick off" phase that you describe (and what I've quoted above), it can take many months and a fair amount of money just to get to the point of "Now what?" as above. And if you were to stop the entire project right at that point and go no further, exactly what genuine business value would the business have gained for their investment at that stage? Absolutely nothing.

The premise of the OP's article is to remove as much of the non-value-delivering busywork as possible - and there's always quite a fair amount that can be removed - and start with the work that actually delivers value to the business as quickly as possible. This further requires a high level stake holder of the project to provide meaningful and frequent feedback to the development/software/hardware teams so that mis-steps (which if the feedback is frequent enough, will be slight) can be corrected easily before proceeding with further iterations along the overall "project".

You rinse and repeat the small-steps-of-work-that-actually-deliver-value and frequent feedback loop until either the client/customer/business has what they want and can then tell you to stop, or the client/customer/business runs out of money. And even if they do run out of money without the project being "complete" in their eyes, they'll at least have had a large amount of genuinely valuable work that's been delivered to them. Of course, if you're in an organisation (or working with people) who are mired in old Victorian workhouse style command-and-control management, this approach to delivering valuable work in small, meaningful iterations without knowing the full cost or timescale up-front (and let's face it, 99% of enterprise run projects have their up-front costs and timescales off by many orders of magnitude so just have useful is that information anyway) can seem like anathema. Like the reaction of the Flat-Eartherers when they were first told it's actually round.

Of course, the problem here is that no PM/BA/Dev.Manager etc is going to admit that a large amount of the work that they do (and, to be fair, are expected to do by upper management - ultimately, they're the ones still stuck in their old-school command-and-control management thinking) is superfluous and doesn't actually deliver value to the business lest they make themselves entirely redundant.

[billybiro]

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.

[NotAllThere]

Project managers are great so long as they stick to their jobs and do what they're told. The only reason the job function exists is because the big consultancies needed something with no technical ability that they could sell to client as "adding value".

[Whorty]

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?

Budgeting, contract negations do you need a dedicated PM for this, perhaps just an administrative person?

How would you decide if you where the client when a dedicated PM was required? Do you think a PM should lead a software development project?

Are you sure you've done Prince 2? To even ask these questions shows a lot of naivety of how projects should be managed. I'd give being a PM a miss if I was you.

[tomtomagain]

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.

I'm a developer with 20 years experience and I agree with you.

I am also a project manager with 10 years experience in PMing, independent of software dev.

When you are running a large project you have to give an estimate, even if you don't have all the information you require. No company starts a project of any significance without at least some high-level understanding of the cost/time.

[billybiro]

I'm a developer with 20 years experience and I agree with you.

I am also a project manager with 10 years experience in PMing, independent of software dev.

When you are running a large project you have to give an estimate, even if you don't have all the information you require. No company starts a project of any significance without at least some high-level understanding of the cost/time.

Again, I don't disagree that you're required by your clients to provide up-front estimates for large projects, but, in your 10 years of PM'ing, just how accurate are those right-up-front estimates? I'd venture that they're highly inaccurate. Yes, as you've said, you refine them over time, but it begs the question just what is the point of providing estimates right-up-front when we know for a fact that they're highly inaccurate and of very little use?

The only answer is that upper-level management/senior executives don't know any other way (or rather are not open to even contemplating that there could be any other way) and are using the useless estimates as a crutch in typical cargo cult, "but-this-is-the-way-we've-always-done-it" fashion. Their antiquated thinking (which is unfortunately all too pervasive) is the very opposite of the more "lean" minded approach, the like of which is espoused by such luminaries as W. Edwards Deming et al.

[Whorty]

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.

There are 3 pillars to a successful project - time, quality and budget. If you can't plan to these early on, and manage to them during the duration of the project, how can you possibly claim to have managed a successful project?

Sure, it's easy to not estimate how long a piece of dev will take and to continue working on it until it's finished. This should hopefully deliver the quality pillar, but likely fail the budget pillar and as you can't give a time estimate you'll fail that too.

Poor developers hate to estimate how long something will take as they don't want to be held to account. Good developers are happier coming up with estimates (and i always add a % slack to cover for the unknown). If you're a good developer, with 20 years of developing software, then you should be experienced at estimating how long your work will take ... if you can't I'd question if you're that good a developer and I wouldn't want you on my project.