Submitted by MikeK on
OK, I am massively relieved after hearing this segment so far, it is everything I hoped it would be! In fact, I have always been curious if MT would ever cast on project management. Finally!
I have been feeling like an outsider in my company as project management is constantly looking like a set of technologies to manage instead of people. This podcast hits all that on the head and I absolutely agree with it and frankly, its a relief to hear as I don't have the same support for the unnecessary complexities of today's PMI and other technology around PM roles. I find them for most projects unnecessary and largely ineffective as they begin to take the place of managing tasks with people.
That is how I like to run projects and definitely get flac for doing that, even though my projects run smooth and well without all the focus on the PM tools and technologies.
Anyway, looking forward to more of this podcast and would love to hear others' thoughts on it as well.
I agree with Mike, these project management podcasts are very interesting.
Mike, Mark, do you have plans to say something on Agile Development and Agile Project Management, for example on Scrum? I'd be interested in your opinion on self-organizing teams.
I really enjoyed these casts...
This cast rang true to my 20+ years of project management experience.
As General Eisenhower famously said: “Planning is essential. Plans are useless.”
Pert chart methodology was created to support the development of the Polaris nuclear submarine systems. Few projects have that level of complexity or criticality.
Herewith some observations from the trenches:
Planning is essential. Without a good plan, you don’t know what people you need, for how long. You also need tools, supplies and infrastructure. Spending frugally and investing wisely require good plans. Aligning with other initiatives requires knowing milestone dates. Planning is essential.
Plans are useless. Once a project starts, Pert/Gantt charts require tremendous effort if they are to accurately reflect what’s happening and remain relevant. For most projects, that level of effort far exceeds the value returned. The critical path tasks shift constantly, and often a “project administrator” is assigned just to keep the charts up to date.
Moreover, the plans are often wrong. You miss things. Effort estimates are wrong. People get sick or leave the company. Requirements change (and rightly so!) Resources don’t arrive when needed. Plans are useless.
Planning gets you started. Once you’re moving, focus on the tasks. Keep each person delivering on time - that's your best chance for delivering on time.
This is my favorite project management moment in cinema…from 3:30 to 4:45 in this clip:
Project Management Question
I too enjoyed the PM casts and look forward to more of them. In your above comment, you say "Effort estimates are wrong.", and then "Keep each person delivering on time". I notice that estimates are truly incorrect, but then where does the real "deadline" come from? How do you set a hard deadline from the incorrect estimates, and then keep "on schedule".
I'm relatively new to being a PM and would like some experienced advice.
Horstman's Law of Project Management - A disagreement
I expected to disagree with the Rules of Project Management podcast. Having listened to it I didn’t actually disagree, but I did find it overly simplistic and idealistic.
I have learned, and actioned, a lot from Manager Tools and I’m not one knocking MT’s output, but still I find myself needing to make these comments.
BLUF - I would add to MT’s concept of project management, by suggesting that projects “boil down to who is responsible for doing something, what they're responsible for, and when they have to have it done by” And who it is being done for.
Whilst the principle of podcast works for me – that the delivery is more important that the administration – I would still suggest that there is a balance. I will give an example:
Every project will have a sponsor (someone who is paying or benefiting from the outcome). This sponsor will require updates and, in my experience, they will judge the PM on documentation and plans. This is because reviewing progress on projects is seldom as easy as flying above a forest and seeing how much smaller it is. And even if it was the sponsor will still want to know when things will be finished, and the certainty of the answer. Providing that answer will require a degree of paperwork and calculation, which will need to be completed, and is at least as important as the project delivery, because it appeases the customer.
Although not considered on the podcast I would suggest that project managers are measured against administration of risk logs, issue logs, gantt charts and the like. These are necessary (evils) to communicate with project sponsors (rightly or wrongly). And often requested by the PMO – who report your administration levels to line management, which then reflects in the PM’s annual review.
I believe, in accordance with PRINCE (the UK project management standard) that all project management methodologies and tools should be used as and when required – and not all are required every time. However, there are basics that are required every time; this is, at very least a documented scope and a plan. And time does need to be spent on both of these, with the plan in particular requiring attention through-out the project. (Please notice that I did not say ‘gantt chart’ or ‘MS Project’ or any other complex tool here).
To use the deforestation example again – you need to plan how many tree-cutters are needed to hit the deadline, you need to plan when the haulage trunks will arrive (obviously not before the tree cutters), you need to plan what to do with the wood (or where to burn it), etc - this planning process is obviously not wasted time. Then the plan will change when endangered wild-life are discovered!
In summary, it is all about people. The podcast, for me, simplifies this to only consider the delivery people. I suggest that PM should also consider the customer and their line management. And both of these people are, in my experience, likely to judge you on the administration which this podcast could persuade you to relinquish.
NB. I have no experience of deforestation and I am against it. I am just using the example in the podcast.
The sum of wrong estimates isn't wrong?
Iann22 hits the core issue: you can plan to cut down the trees, knowing that on average you log x trees every y hours. But once you get in the forest (Stephen Vincent Benet, anyone?) there are ravines and unexpected weather that slow you down. Then the terrain is flat and the sun comes out, and you make up for lost time.
The law of averages works out. Your estimates shouldn't all be underestimates (right!?) and should therefore add up to minimal impact.
Sometimes you just don't know, and you're guessing. You move those tasks as early as possible, and you keep your eye on them. You adjust as you go.
Maybe an endangered species stops the work. Then you have to escalate. This happens often. Senior executives expect to be informed. It's when you try to hide everything as being green when it isn't that you get into real trouble.
Look at any large public project with a hard deadline. The Beijing Olympics is a good example. The deadlines are often imposed, and are not derived from the PERT chart. Here you just work backwards: If the project has to be done Aug 1, what has to be done by July 15? and for that, what has to be done July 1? And then June 15.... you get the idea. This is "essential planning."
Does that make sense?
Project Management podcast
The podcast chimes with my experiences as a Project Manager - I think of my time as being divided between "round the front of the project" (managing the people, their tasks, their deadlines and the problems that come up) and "round the back of the project" (doing administrative tasks such as documenting the progress of the project, updating the budget and schedule, creating and circulating progress reports etc.)
I have noticed that some project managers are a lot more comfortable "round the front" and some prefer to be "round the back" - I think it depends on personality and prior experience. Too much time spent on either front or back can be bad - a "round the front" extremist risks getting so embroiled in one aspect of the project that work on some other part is neglected. A "round the back" extremist documents exactly how the project going to hell, but without intervening to stop the rot.
Project Management Question
What you say does make sense. I have made a best guess at the beginning of a phase of my project on the next deadline with some milestones on the way there. Is there any difference if you are DESIGNING a widget for the first time and don't know how long things really will take, versus cutting down a tree that is more well-defined? What I've seen is all throughout a project, NEW tasks will pop up because something didn't work quite right like it should have. How do you handle that? Mark's comments about how no one can predict the future come to mind. Also, I thought of his comment about having to rely on the one guy whose been around forever and just tells you how long it SHOULD take. Suppose you ask the engineers to estimate how long it will take to design their section of the project, and they have no idea (never have kept track, or it's too different from something else they've done). They end up guessing a few weeks, and in a few weeks they come back and say it doesn't work right and they have to change a lot of it. Is that typical, and if so how can you work to a real deadline then?
I appreciate your good advice.
Research and Development
Albert Einstein is purported to have said, “If we knew what we were doing, it wouldn’t be called research.”
My team is an R&D team. Indeed, innovation can’t be scheduled like cutting down trees. “I need a breakthrough by next Thursday!” I wish.
Things get trickier in this case. In the formalisms of PERT, each estimate has a probability curve associated with it, and the overall plan takes this into account. This is far beyond what most project sponsors are willing to bear (you’ll lose them at: “The standard deviation of the expected completion date is….”)
You’re doing research, not development. Different rules apply.
Some rules to follow when your project requires tasks of unknown duration or skills:
1. Your project sponsor needs to know that you’re in unexplored territory. Let them know that this is research. Be confident, upbeat, and honest. (Don’t worry: most companies don’t put folks in charge of research projects unless they have already established some sort of track record.)
2. Task decomposition / work breakdown analysis becomes very important. Even if you don’t know how to make an Illudium PU-36 Explosive Space Modulator, you have to start somewhere. And you probably know how some of it has to work. So you carve out the knowns from the unknowns, and put your best estimates around them both.
3. Go back to your sponsors. Share the unknowns with them. You should DEFINITELY have a plan for turning the unknowns into knowns. Let them know what those research milestones are (“we have to separate the PU-36 from the PU-38 first. We’ll have the prototype centripetal separator built by April 1st….”) so that you have milestones to track.
4. Keep your sponsors informed. When you know that you will hit or miss a milestone, you let your sponsors know right away. Don’t wait for the milestone date.
5. Adjust in real time. “The centripetal separator requires a flux capacitor, and that’ll take an extra two weeks…” and make sure your sponsor knows it. And while the separator might take longer than expected, the triggering mechanism might fall into place quickly. You never know. That’s why communication is so important.
Keys are: the relationships that allow for honesty (they know you don’t know how long it will take) and communicating changes effectively.
And about those deadlines...
Keeping to the deadline in a high uncertainty project usually implies the "iron triangle."
If time is fixed, feature set or resources must vary. The design will have fewer features, or it will be more costly. There are a lot of resources for time-boxing projects.
This is why great designers are in high demand. If you find that person who can deliver well in a timely fashion, you've got gold.
Do you want it quicker,
Do you want it quicker, better or cheaper? You can choose two!
LEAN procedures in Development do not eliminate planning, but the level of detail in the planning is dependent on the time distance. E.g.:
* The first two weeks are planned down to tasks, adjusted weekly or daily
* The first three months are planned only on deliverable packages, adjusted 2-weekly
* The full project is planned roughly in stages
Death-by-MSproject is when you are planning on Jan 27, 2009 which software engineer will be writing the WumpyWidget on May 29, 2011. Or which lumberjack is cutting down what tree tomorrow at 3:17pm.
The subject of graduates on Projects
I am new to Manager Tools and Project Management. My firm has given me a few piecemeal projects, I presume to "see how I go." I understand Mike's and Mark's need to find and seek the best people for the project. Early on in my engineering career, the best way to learn was to do the work. But I knew that I was slow, I was asking many questions, made lots of mistakes and I knew I certainly wasn't the best person on the job. If now, as a Project Manager, I should seek the best people for the job, where does the graduate fit the picture? Grads need to learn their craft as they are the future of the firm and of the engineering profession. I know that I can get a senior engineer to complete a task in 2 days, but it may take a grad a week or more.
I'm interested in getting opinions and thoughts out there from people who have managed graduates as part of the Project Team, and still delivered the project under budget and on time.
The best aren't necessarily the most experienced
It's the old conundrum: how do you get the experience when only the experienced are being hired?
On most projects, there are roles for experienced and for junior folks. There are opportunities for stretch assignments. Experienced folks don't want to do the same things over and over either, and they'd like to take on new roles.
The best people are motivated, dedicated, thoughtful, diligent and collaborative. The junior guy might ask more questions, but the senior guy who could do it faster is doing something else.
So good managers know that they need to coach, delegate and stretch their best people, regardless of their level of experience.
Graduates in projects
Cronze, in my opinion there are a number of points to be considered when deciding who is the best person for the job, the graduate or the experienced engineer. 1. Is this a complex task? 2. Is the task on the critical path? (does it have float?) 3. What is the cost rate of the graduate? 4. What is the cost rate of the experienced engineer? 5. What is the visibility to the customer? 6. What are the customer's expectations? Answering these questions is a good starting point to resource allocation in my humble opinion.
I've had HUNDREDS of
I've had HUNDREDS of "graduates" on projects. And by this I mean high school graduates, to say nothing of college/university graduates.
They do just fine as they're stumbling about (as I did and everyone else I know did, in the beginning) and are quite serviceable to a project.
They respond to time and attention from the manager, clear deadlines and communication about responsibilities, and feedback on a regular basis.
Most people are so stunned by the behaviors we recommend that it is only those WORKING on the project who realize, "yes, this is different, but I like it and it's working!" Everyone else just dismisses the approach as different.
All successful projects have been so because of a focus on who does what by when. All the rest is bolt-ons to address that. But why turn a knob that turns the ACTUAL wheel when you can just reach around and turn the actual wheel?
We haven't oversimplified anything, sorry. It just appears overly simplistic compared to the overly complex way that non-people-focused PMs have developed to address what ends up being work done by people, after all.