Every project needs a project vision: the reason the team is working on this project.

When you define the project's value early in the project, the more the project team is likely to tell you whether the project makes sense--or whether you're starting an impossible project. If you can't articulate the vision, chances are good that you're starting on an impossible project, because there's no way to end a project with no vision. A useful vision is compelling to the project team. And it helps the team make decisions about what's in or out of the project.

Here's how you create the project vision:

    1.    Define who the primary customers of the project are. They could be the mass market, existing customers, new customers, or a specific market segment.
    2.    Define the one major focus of the project. This could be a specific feature, or the general approach. If you're new to agile and you're starting a pilot project, you might want to say, "Use agile techniques to see how to adapt them here." A project doesn't focus on five things; it focuses on one overall vision. If your project requirements are too broad to encompass in one vision statement, maybe your project is really a program.  A project has one deliverable. A program has one overall deliverable and is composed of sub-projects, each of which has a deliverable.
    3.    Write as much as you need to, and then edit until you're down to two to four sentences. If your vision is longer than four sentences, you haven't described the project focus yet.

Here's how I do this. With the project team, we decide who the primary customers of the project are. Now, if I know the major focus, I explain it. Otherwise we try to define it together. Now, as individuals, we write our sentences, on stickies. We post them on the wall, and read them out loud, seeing which sentences make sense. We choose sentences and edit. Once we're down to no more than 4 sentences, we are done.

If you're on a project without a vision, stop right now. Take 30 minutes, define it, and get back to the project work. The whole team will benefit, as will your customers.

I teach project management and estimation workshops. Every time I teach estimation, someone asks, "How can we get the perfect estimate?"

You can't. Estimates are guesses. And, if you are multitasking, every estimate you have is wrong. Guaranteed.

But you still need to figure out when things will be done. Instead of estimating how long a task will take, I prefer to estimate how many small things I can complete in a week. And, I make sure I get to done on each task before I take on another task.

One of the problems of estimating large tasks is that we tend to estimate in units that are too large. If you estimate in weeks, you'll be off by weeks. In days, you'll be off by days. In hours, you'll be off by hours. Over the course of a project, even estimating in hours can obscure the actual duration remaining for the project.

Instead of using scope as the base, I use a timebox. Instead of asking, "How long will this take?" I ask, "What are all the small tasks required to complete this piece of scope?" Then I see how many of those will fit into a week.

If you're working with other people, and are using a Delphi method for estimation, you'll discuss your estimate. You'll hear things like "If Danny does it, it's only a 3. If I do it, it's a 5." I always take the upper estimate. Why? Because if Danny is so good, he's not going to be available. He'll have questions to answer or some other task that's a higher priority. I'll do it anyway. And, if I practice doing these tasks I'm not so good at now, I'll get better pretty quickly.

Think hard about whether you want a good estimate or if you want the work done. Estimating at the beginning of the project is often a waste of time. The more work you get done, the better your remaining estimate will be. 

I'm at the PNSQC conference this week, and gave a talk where I said pragmatic project managers select a life cycle that manages the big risks for them, so they can pay attention to the other risks. At some point, I said, "If you ever hear:"

• If we could just get the requirements right
• If we could just get the architecture right
• If we could just get the design right
• If we could just get the testing right
• ...

Anything you hear that starts "If we could just" and ends in getting something right means you are not choosing a life cycle that manages the risks you have. That's a project smell.

Some projects are big, risky, complex, scary, whatever. You still have to do them. But you can choose which risks you can allow your life cycle to manage for you.

I would love to know enough about my projects to predict them perfectly. But, I rarely do. That's why I use rolling wave planning, no matter what life cycle I use.

In a serial life cycle (waterfall or phase gate), you can lay out all the major milestones if you know what they are. But you don't plan in detail how you get to each milestone. Instead, you plan for the next 4 weeks--no more than 4 weeks--in detail. The way I do this is:

• Get everyone on the project in the same room
• Decide on a milestone (not necessarily a major milestone, just a milestone) that's a month away
  
• hand everyone a thick black marker and a pad of yellow stickies. (I need people to use the 4"x6" stickies because I can't read what they write on the smaller stickies. If you have people with younger eyes, use whatever size stickies you want :-)
• I ask this question "What will it take you to achieve this milestone?"
  

Then I get out of the way. I let people write their tasks down and argue about who has to do what. I make sure no one starts a physical fight. If we have questions, I keep a parking lot of stickies on one side. I ask people to put their stickies in time order, left to right with the earlier tasks on the left and the later tasks on the right. If there are dependencies, note that with sticky placement.

I request that people create small tasks, inch-pebbles (one- or two-day tasks that are either done or not done). If people have week-long tasks, I work with them individually to break the tasks down into smaller pieces. 

What you have now is an on-the-wall-sticky Gantt chart. But you only have 4 weeks worth. Now you have a couple of choices of how to proceed:

1. You can either ask everyone to get together to do this planning for one more week every week, or
2. You can ask people to plan their own tasks weekly and once you've achieved a major milestone, now you get everyone back together.

The key is that you always have a month's worth of detailed planning. You never have more. You never have less. If you laid out the major milestones, everyone knows what they're trying to achieve as a group. If you're managing the project, you have much more insight as to how well the plan is going vs. the actuals.

With an iterative life cycle, such as the spiral life cycle or RUP, or with an incremental life cycle such as staged delivery or EVO, this is even easier, because these life cycles deliver prototypes or finished code into the code base earlier.

With an agile life cycle, I use rolling wave planning not for the schedule, but to better my prediction about which features might be delivered in which iterations (assuming the product owner doesn't change his/her mind much about the ranking of features).

No matter what life cycle you choose, consider adding rolling wave planning to your toolbox. Especially if you can't predict much. You don't have to, and you gain tremendous benefit by seeing the details for the next few pieces of work.  

Even before I started using agile approaches, I used timeboxes. I actually started to timebox my work when I got my first review as a developer and my boss said, "You don't finish anything. You get 98% of the way done and then you stop." Well, that's because I hate those little details at the end of a task.

Details are not my friend. I can manage them. I can do them. But I hate them. I would much rather eave my hands and say it's done when it's close enough. Well, close enough for the rest of the world appears to much closer than it is for me, so I started using timeboxes when I got that feedback.

I sometimes use timeboxes of no more than 10 minutes when I need to get started on something and I have no idea where to start (such as cleaning my office). I use timeboxes of an hour when I need to see how long something might take and I don't know how to estimate the task. That's enough time to do something useful but not so much time that I get bored and go do something else.

In projects, I frequently use timeboxes of 1-4 weeks, just as the agile lifecycles do. But even if I'm not using an agile lifecycle, there's something quite powerful when I tell the product managers, "You have 2 weeks to define the requirements. We're starting on the architecture after that, so get the good stuff in first." Then, when I tell the architects, "You have 2 weeks to fight about the architecture, and then we're starting on coding." Sometimes, if I think a feature is risky and maybe not so valuable, I'll timebox the coding of it.

One technique I started using back in the '80's was to timebox building and integrating and testing a feature. (This is incremental development, if you weren't sure of what to call it.) I started this when one of my talented developers got lost in the code. He fell in love with a feature, and was adding to it, expanding it, make it fabulous, but he hadn't integrated or tested it. I gave him a week to check the code in, making sure he didn't break the build.

I suspect he called me a variety of names, none of which were particularly nice. On the other hand, he finished the work because he didn't let anything get in the way of this task.

That's the value of the timebox; it focuses you on a particular task. It makes you promise yourself that you will finish this task before the end of the timebox. That focus and urgency help me finish my tasks on time. And, if a task takes longer than the timebox I've allotted, I have learned a lot about that task.

So, if you, like me, have a difficult time with the details, or if you have a tendency to go off on tangents, or if you would like to know how long things actually take, consider using timeboxes. Your project manager will love you :-), and you'll be a lot more productive. 

I was speaking and teaching last week at the PMI Regina's PDC (Professional Development Conference). I taught an estimation workshop and we had some illuminating discussions about what to do when people on your project can't estimate. We all agreed people tend to be either optimistic estimators, where they think the work will take less time, or they will be pessimistic, where they think the work will take longer. Rarely does someone change. Our discussion about what to do when someone consistently miss-estimates was the part where I saw servant leadership.

One project manager said, "I don't want to crush someone's hopes or ignore their hard work, but how do I explain that each and every assignment he's been late on and I just don't believe his estimate?" Good question.

People need feedback on their estimation, and a project manager might be able to help the person see where this estimation suffers from the same problem as the previous estimations.

That's where the servant leadership comes in. A PM who's not a servant leader will think, "Hmm, your last 5 estimates have been off by 50%. I'll add 50 %," and be done with it. But a PM who is a servant leader gives feedback and asks for a re-evaluation, "Joe, you might not know this, but your most recent 5 estimates have been under-estimated by 50%. I don't want to blindly pad your estimate. I'd like to help you learn to estimate better. Is that ok?"

If that's ok with Joe, now you have a way to help the other person learn to estimate better. I like breaking tasks into inch-pebbles (one- to two-day tasks that are either done or not done), starting with user stories, or using Delphi estimation as a way to help people learn to estimate smaller tasks and see when that work is actually complete. One guy I worked with said, "I always thought it just took a few minutes to set up a new branch. But when I tracked what I did, I realised it took me closer to an hour, by the time I was actually done and ready to start writing code and tests. Who knew?" Until he created inch-pebbles he had no idea how complex his work actually was.

Great project managers serve the project and the people on the project. They don't take estimates at face value, without understanding how the estimate came to be. But they don't autocratically change the estimate without providing feedback.

If you're a leader in the organisation, whether you're a team lead, a project manager, or a manager, think about how you can serve the project, the organisation, and the people. You'll get better results if you remember the people.