— 30 November 2005 —
As I said in the previous post on this topic one of the reasons a PM gets rewarded, traditionally, is bringing the project in on time.
On time. What the hell does that mean? The creative side of me says the work will get done when it gets done. Frankly, I think there is a lot to be said to that approach. But there are the needs of the stakeholders (including users) to consider. Sooner usually is better than later in their minds. But, keep in mind that whole “quality” thing as you go, okay?
The trouble is, unless you’ve been given a hard end date (like the world will end unless we convert everything to a 4-digit year), on time is really difficult to do. In the perfect world you’d have all the right resources (people and systems) work 100% of the time on the effort, with a clear vision of what you need to build, and support for everything you need to accomplish your goal. Usually you start with none of these.
Throughout the project you will be managing the typical triangle of scope, cost, and time. Conventional wisdom is that you only get to have 2 of these work out well. One of my biggest peeves are projects that are started with unattainable scope items, timelines that are unrealistic, and a budget that gives you the impression someone just emptied their piggy bank on the table and it adds up to nine-pence.
So what is a PM to do? Be a Timeline Stickler anyway. But be a stickler in a pragmatically compassionate way. :)
The best thing you can do is try to convince the people working for you to give realistic estimates of effort and duration. Remind them that they are working on multiple efforts. They get sick from time to time. They go on vacation. They hate doing this kind of project and drag their feet. Everyone hates Bob.
Seriously though, all of this plays into your ability to bring something in on time. I suspect that if people would take a serious look at their personal and professional schedules they really would get a decent idea of how much effort they could put into your project.
Humans tend to aggregate tasks that they’ve done over and over. Some of the people working on your project will be new to their role, others can do it in their sleep. From a timeline perspective, I worry more about those that do it in their sleep.
Here’s whyâ€¦ Suppose you want to see usability done on the new web site. What will it take to do that? (The “What will it take” game is similar to the “In order to” game which we will go into at some other time.) You need a working prototype and usability participants to have a usability test. What will it take to do that? You need a workflow to test. You need to write a report. What will it take to do that? All of these activities take time. Yet you are often given an answer of 10 hours over 5 days for usability.
If you are only testing 2 people on one workflow that goes over 2 screens and don’t plan on writing a report, I bet 10 hours will suffice. Beyond that, and you probably need to up that estimate just a little. A designer might think that 10 hours will sound great to a PM, but as a PM I highly suggest being politely incredulous about every initial estimate.
Something you might consider is “Horizon Planning” or “Stage Gate Planning.” As a PM you will always be pushed as to what the go-live date is. But if you have a project that is budgeted for 30,000 hours, can you really plan out an entire project? This is where horizon planning comes in. You plan in detail only the stages of the project that you can “see.” The rest is a SWAG and it’s fine to stay that way.
With horizon planning, you can have conversations with the primary stakeholders near the end of each stage about the work accomplished and gauge the progress and potential success of the project without going too far down the wrong path. “During requirements gathering we discovered 19 new requirements (that you forgot to tell us) and we suspect it will add to the time line. What should we do?”
You make your decisions and move to the next stage. All the while you have saved your people from sitting in conference rooms for 3 months at 4 hours a day trying to plan out a detailed end-to-end schedule. Especially good when you need to add those 19 new requirements to the scope of the project. Want to spend another month replanning an end-to-end schedule? Me either.
The plus side to being a stickler on planning is that you get better at it over time (stickling and planning). And the better you get, the more likely it becomes that you will be able to look to past efforts for help. Start with the past project’s plan as a workable template. And reusing plan templates saves everyone time and therefore money. Again, making you look smart and pretty. :)
Next up is the second (this being the first) of what I consider to be the least important, but still necessary attributes: How much will your bonus be?