Project Schedule and Budgeting

Oh, the Horror of Just One More Delay

Mary is a public relations manager for a nonprofit agency. She is charged with redesigning the organization's web site and integrating it with a new financial system the organization is implementing. Although Mary does not have any experience with web site development, she is a regular user of e-mail and sometimes reads popular news web sites and makes online purchases. Mary writes down all the things she wants the new web site to do and then asks her friends for recommendations for consultants and firms. Over the next several months, she gets ten different proposals, from 2 pages to more than 50 pages, ranging from a few hundred dollars to over $30,000. With such a wide range of proposals, Mary takes nearly a month to select the two firms that she likes best and schedules interviews with them. Although the proposals are very different and seem to propose different technologies, Mary selects the firm that seems to do the most work with nonprofits and signs the contract for services.

Mary needs to move fast because she had only budgeted 2 weeks to select a proposal and 2 months to develop the web site in order to meet the deadline she was given by her boss. She schedules the kickoff meeting the same day the contract is signed.

The day of the kickoff meeting, Mary's boss, Susan, is called away to handle an emergency and cannot participate in the meeting. The development manager is not interested in the project and will not participate either. Only the CFO of the nonprofit is able to attend. The kickoff meeting goes very well, but toward the end of the meeting, it becomes clear that the CFO has not yet approved the project budget and has some problems with the contract Mary signed.

The consulting firm is ready to get started on the project, but Mary asks them to hold off while the nonprofit updates the contract and secures the funds. Mary and the CFO decide to review all of the proposals a second time and then rewrite the contract for the firm they selected. The new contract includes some requirements that were not part of the nonprofit's request for proposal (RFP) or the consulting firm's. Consequently, the consulting firm provides a change order for the additional work.

Finally, 3 months after the kickoff meeting, the project is ready to move forward, and Mary asks the consulting firm to prepare the designs in just a week. The consulting firm moves quickly. In just a few weeks it completes three rounds of design and Mary approves the final version. Development begins, but after a week, the nonprofit's CEO sees the designs for the first time. She halts the project while she revisits the designs.

Seeing the designs makes the CEO realize that she really needs to proceed with that rebranding effort that had been on hold for over a year, including a new logo and corporate color scheme. Mary is put in charge of writing an RFP to hire a branding firm to come up with the logo. The consulting firm is asked to put the project on hold for a month while the nonprofit goes through a rebranding effort. One month stretches into two, then three.

Fast-forward six months. It is now over a year since the project began. While the project is now 75% over budget, development of the web site based on a new set of designs is complete. The CEO and CTO are frustrated with the web site consulting firm and the branding firm because they believe both projects have taken far too long and both are over budget.

Protecting the schedule to avoid these situations is vital to project success. This chapter offers guidance on preparing a practical schedule and budget that enable you to stay on track and track your progress.

Estimating Time (It's Hard!)

One of the most critical tasks a project manager will undertake is estimating budgets. This is critical because task estimation will set the project scope, define the resources that need to be allocated for the project, and impact the proposed project schedule.

Because estimating is a hard task and is as much art as science, task estimation has a bit of a bad reputation. But fear not, intrepid reader, for you need not be so leery. Here are some tips to make estimating easier.

Principle #1: Account for Unknowns

It is impossible to accurately predict everything that might happen during a project task. There is always going to be the chance for an unexpected event to increase the time needed for a task. Consider adding a small amount of time on top of your estimate to account for this.

Principle #2: Break the Task into Parts

When thinking about a task for a project, break it down into pieces. Do not estimate the whole, just the parts. For example, say you are estimating the Drupal theming task for a modest web site (Drupal is a content management system). You might break this task down into splicing up the mock-up from the designer, creating the CSS and HTML, setting up the template files, and programming the views and blocks.

Principle #3: A Task is More Than

Development

This idea might seem simple, but it is worth mentioning: the time to complete a task is only partly developer time. Do not forget about additional time for quality assurance (QA), meetings with the developer to discuss the technical specification, time to collect feedback from the client or internal stakeholders, and time to deploy the project to a staging server (and, if relevant, a production server).

Principle #4: Ask a Developer (But Add Time)

If you are estimating a task that you have not actually done in your past work life, stop. Find a developer in the office, provide a simple summary of the task (describe the task generically, but do mention any parts of the task that you consider to be challenging, difficult, or nonstandard work), and ask them how long it would take.

Now, take their estimate and add 50%, along with their developer bias (see Principle #5 ).

Wait, why should you add 50%? Because a developer is likely to estimate how long it will take them to sit down and knock the task out. They do not tend to think about the several rounds of refinements they are likely to do, nor do they think to include general project management and quality assurance time for a task. All of the time spent beyond what they do is likely to be a mystery to them, and so it simply will not appear in the estimate.

Principle #5: Know Your Bias (or, Review Your Actuals)

Providing good estimates for projects is an ongoing learning experience. It is important to take a moment at the end of a project phase, or at the end of a project, and check how long a task actually took. Compare the actual time the task took to complete with your original estimate. A pattern—or bias—will quickly emerge. You will likely be consistently incorrect in one manner or another, be that too high or, more typically, too low in your estimates.

Once you start to see your bias, be proactive and adjust your initial estimate by enough to counteract it. For example, if you think a task is going to take 3 days, and you typically underestimate by 50%, then estimate the task as 6 days.

Principle #6: Use Software to Help Report on Your Estimation Performance

There are many different project management software vendors. Several of them (see the Appendix) include reports that can detail the estimation accuracy history of individual team members. This makes it easy to track real-time data on estimation bias, which will help improve your estimates.

Principle #7: Resist the Temptation to

Underestimate

There are many reasons why a project manager might feel pressure to compress an estimate. This pressure could come from a client with a restricted budget or a superior unwilling to allocate resources sufficient to complete the project.

Resist this temptation. Compressed estimates greatly risk project success and client happiness. A task takes a set time to complete. It does not take less or more; it takes the time it takes. Having a tighter budget means that the project manager will feel pressured to complete the task in less time. This pressure gets passed to the developer. Nobody likes to work under this kind of pressure.

An underestimated task will deliver pain to either the client or your superiors: if you complete the task to spec, the client will be happy but your project will be over budget. If you cut corners, the client will be (justifiably) unhappy.

Insist that if less time has to be spent on a task, then features have to be removed from the task requirements. Reducing the time spent should reduce the scope accordingly. This way, you can complete the task on budget and meet the expectations of the client.

Preparing the Project Schedule

The goal of the project schedule is to set the project delivery expectations with the client. A good schedule has two components: a reasonable estimate for project completion and clearly identified milestones for critical deliverables.

Creating a project schedule is another frustrating part of project management that is based in estimates (read: guesses). Although it becomes easier to write schedules as you learn how long similar phases tend to take in other projects, here are some pointers that can help you write the schedule.

Principle #1: Identify Each Major Phase (but Be Concise)

Schedules should be simple to read, painless to update, and easy to e-mail. You do not need every minor project phase on a schedule. You do not need a giant ugly GANNT chart (they might seem like essential project management tools, but they really might only be applicable to projects larger than those we discuss here). You are not building a building; you are building a web site.

For a typical two- to three-month project with a budget of around $55,000, a ten-item schedule will be fine. For a four- to five-month project with a budget of $100,000 or more, you should have a project timeline with specificity and deliverables week-by-week.

Principle #2: Identify Critical Deliverables

A project schedule is most helpful to you when it can be used to clearly demonstrate to the client where delays can occur and who is responsible for critical deliverables. Make these clear on the first draft of the schedule and point them out to the client when you review the schedule together.

For example: if you have a project where the client is providing their own design, then you should have a step on your schedule that clearly states when the design must be completed, approved, signed, sealed, and delivered. When that date arrives—and passes—it will be very simple to alert the client that the project schedule is delayed.

We often label a critical deliverable “Critical Pathway,” so a schedule item of “Provide logo and branding guidelines” becomes “Critical Pathway: Provide logo and branding guidelines.”

Principle #3: Add Some Padding

There will be a delay in the project on your end. Something will go wrong. Just accept it. Maybe a team member will leave, or there will be a death in the family of a developer who will need time off, or maybe a high-profile support project will implode, requiring lots of unexpected attention to fix. Another project could appear that upper management deems higher priority.

The lesson is here is to embrace an old adage: assume the best, plan for the worst. Add some padding to the schedule.

Principle #4: Learn Your Team's Bias

Because you rely so heavily on the estimates of your team (as their smaller estimates trickle up into your own larger estimates), it's vital to take an active role in learning and helping to improve their ability to make accurate estimates.

Principle #5: Alert the Client to Deadlines

If a critical deadline for a project deliverable is approaching, send a short, polite reminder to “check in on the status.” Some project management tools (see the Appendix) do this for you automatically.

Principle #6: Include the Client's Critical Path Deadlines

Call out any key delivery dates that the client has identified clearly, which may or may not be project-specific.

Formatting the Schedule

If you use a project management tool (see the Appendix), the schedule is likely to be provided for you in a clean and professional manner. In these cases, assuming your clients have accounts, you can simply send a link to your client to access the schedule in that tool for review and discussion.

If you are preparing a schedule manually and want to send it to the client, you will need to format it yourself. A simple schedule of around 12 to 15 items can be presented cleanly in an e-mail. Anything longer would look better in a software tool. For example:

Hi Team,

I've prepared a draft project schedule for the development of the web site.

Kindly take a look and let me know if you have any questions, changes, or concerns. I would be happy to setup a conference call to discuss further if you like.

Draft Project Schedule

= = = = = = = = = = = = = = = = = =

4/1: Project schedule and requirements document ready

4/10: Server specs provided

4/10: Critical Pathway: Provide style guide, logo

4/15: Critical Pathway: Approve requirements document

5/5: Design Mock-up Ready

5/12: Critical Pathway: Design feedback

5/20: Critical Pathway: Provide existing content

5/20: Critical pathway: Provide GAC photos

5/20: Critical Pathway: Design approved

5/20: Critical Pathway: Server hardware, SSL cert ready

6/20: Content migration complete

6/25: Site ready for ICANN review

6/30: Drupal training, part 1

6/31: Drupal training, part 2

7/15: Site ready for launch

Cheers,

{call sign}

Keeping a Close Eye on the Project (without Micromanaging)

Maybe, like us, you have had the experience of trying to straighten up a closet and getting distracted. While you are organizing a shelf, you discover that box of networking cables you had been meaning to sort through. Then you come across that broken webcam and you remember you now have the missing part, and start to fix it, but you cannot find the cable. Then you discover another box with cables that need to be sorted and cleaned out. . . Before long, you are 2 hours into a task on which you had planned to spend only 10 minutes.

Development can be like this. Even really great developers can get distracted with tangential work. What started out as a 1-day project can quickly explode into a weeklong project if not planned and managed well.

An example: a project manager asks a developer to participate in a meeting with several other team members to discuss a new client project that needs to be scoped out—a web application optimized for delivery on mobile devices. During the meeting, the team decides to look around at the existing products to see if one might be a good fit. The project manager asks a developer to check out three products that might provide a good starting point for the mobile application. The project manager thinks this is a 1- to 2-hour task. The developer thinks that this sounds like great fun. Three days later, the project manager checks in with the developer and finds that the developer has put 16 hours into evaluating, downloading, installing, and prototyping each of the tools. Now, the project is 2 days over budget before it has even been officially approved.

Most developers like technology, and many good developers are good at what they do because they like to push the boundaries and discover new applications and new approaches to solving problems.

Your challenge as a project manager is to guide this creative energy to ensure that it remains productive for your client. So how do you do this? No one—especially a developer—likes to be micromanaged.

You need to be able to keep developers on task and on schedule without having the appearance of looking over the developer's shoulder. Here are some techniques for managing a developer's time without making it look like you are sitting behind them while they code.

• Check in: Ask the developer to check in with you after spending × hours on the project, regardless of where they are with the project. This request is explicit and will provide you with a way to ensure that the he is heading in the right direction. For example, “check in with me after you have spent 4 hours on this task so we can review your code and the approach you have selected.” If the developer is on the right track, create the next check-in for 8 hours, and so on. If the developer is not headed in the right direction, create the next check-in for 2 hours so you can confirm that he is back on track. Consider having developers revalidate (or adjust) their estimates when you check in. Eventually, most developers will begin to feel bad when it is clear that their poor estimates are responsible for a large percentage of slippage. Recognizing the problem is the first step toward dealing with it.
• Milestones: Chunk the task into a series of discrete milestones. Have each milestone be a 4- to 8-hour task. After each milestone, have the developer check back with you so you can evaluate his progress and provide feedback. As the project gets further along and you have more confidence in the direction he is taking, increase the size of the milestones. For example, if you are building a web application, have the developer implement a single screen that will display data from your data source.
• Peer review: If you do not have the technical expertise to be confident the developer is headed in the right direction, recruit a more senior developer you trust, and set up a peer-to-peer review. In some cases, you may prefer not to be in these meetings so that your senior developer can give the project developer feedback without having the developer feel like he is not performing. Peer reviews are also a great tool to help developers learn and improve. If you have a new project, try having a peer review after the first two days of development and again after the first week.
• When can you demo it for me? If the developer is resistant to other techniques, you can always try the old standby, “When can you demo it for me?” This causes the developer to provide you with and buy into their time estimate while recognizing that you will be evaluating some functional aspect of the project. So, if you are working on a new search filter, and the developer says he will be able to demo it by the end of the day Thursday, set up a meeting for Friday at 9 a.m. right then and there to review the completed search filter with your developer.

So, with these techniques in mind, what would have been the right way to handle the vignette described in the beginning of this section?

• When outlining the task, the project manager should have specified that the developer spend no more than 2 hours on the project before checking in with him. If the company was using a task-tracking system, 2 hours should have been set as the initial maximum time.
• In addition, the project manager should have talked with the developer after the meeting, and been explicit about his expectations. If the developer thought that 2 hours was unrealistic, he would have had the opportunity to request more time for the project.
• If it was necessary to install and test each of the tools, the project manager could have created a line item in the budget for Existing Product Research and Evaluation. This way, the client would be able to appreciate the testing effort, and review the results with the project team to determine which, if any, of the three tools might be a good fit.

Handling Out-of-Scope Client Requests

No matter how well you gather requirements and identify the features of the project, new ideas will always come up during development. This is natural and impossible to avoid. The occurrence of these ideas does not mean that you failed to identify key requirements (though it can); rather, it is merely an organic part of the project development process.

It is unlikely that your client has ever gone through a thorough requirements gathering process before. Once they experience this process and begin to really spend time thinking about their project, other ideas will materialize. As the client talks about the project with colleagues and partners, other similar projects are likely to be mentioned, leading to still more ideas.

Your goal as the project manager is to ensure the project succeeds. The most common threat to a project is scope creep. If scope creep occurs, your project may fail. But, if you manage scope creep well, you can save your project's schedule, budget, and quality while keeping the client ultimately happy.

Here are the eight tricks to managing client requests like a hero.

Principle #1: Be Clear from the Start

It is vital to set the tone for how out-of-scope requests will be handled the first time the client makes such a request. Manage this correctly the first time, and every later request will be easy to handle.

Principle #2: Don't Stifle Enthusiasm

You do not want to stifle a client's enthusiasm when they have a new idea. So, respond positively and honestly. Be interested in the idea.

Principle #3: Don't Let Them Sit

There will likely be two kinds of requests. The first is for a modest change (1 to 4 hours) to an existing feature. The second will be far more complex and likely represent a new module, page or section. It is important to ensure that the feature request goes somewhere and does not sit unaddressed. For small changes, see Principle #4. For larger changes, see Principle #5.

Principle #4: Maintain a Feature Request List

When the first modest out-of-scope item comes in, take this opportunity to start the feature request list. This can be a simple spreadsheet that lists a short description of the request, who made the request, the date the request came in, and any reference to your internal issue tracking system (like a case number).

Your e-mail response should be clear that the feature request list is for out-of-scope requests that will be evaluated toward the end of the project if the budget allows. Once you start this list with one item, you can easily shepherd other out-of-scope requests to this document by simply writing, “I'll add this to the feature request list.”

Principle #5: Do Not Be Afraid to Use Change Orders

Handle larger (more than 4 to 8 hours) out-of-scope requests with a change order. A change order is a simple document you use after a project has started to detail the cost of adding an out-of-scope feature to the project. When a feature request comes, respond with interest, but mention that it is a nontrivial modification, and ask if the client would like to see an estimate of the cost to implement this change.

A clear change order representing the cost of implementing an out-of-scope request allows the client to decide just how much they think this feature is worth. When it is free, the feature is always a good idea. When it has a price tag, things change.

For more information on change orders, see the next section, “Understanding Change Orders.”

Principle #6: Resist the Urge to Do Everything

If you are the kind of person who likes to just take care of things (many call this type A), be aware that this will make it harder for you to manage scope creep.

Principle #7: It Will Not Be the Last Request

Our fearless project manager might find the urge to complete a modest refinement because he feels that this has to be the last request in the project. Do not do this, because it will not be the last. The moment you feel like you just heard the last request is the moment the client decided to create ten more.

Principle #8: Do Not Feel Bad

When the scope creeps in a project, you lose, the client loses, and the project loses. You might feel like you are being unhelpful by pushing away all requests, but a project free of creep tends to finish on time and on budget.

Understanding Change Orders

It is important to address four key points in a change order:

• The Change Description offers in plain English a concise description of the new features to be added to the project. A concise bullet-list would work as well.
• The Schedule Impact makes clear any changes to the project schedule.
• The Design Impact outlines any changes to the database or application architecture.
• The Cost Impact states the cost, usually in days of effort with your daily rate specified.

Most change orders can be short or, at most, two to three pages, and include these elements:

• A standard cover page you use for other documents, like scopes of work and requirements documents;
• The change description, and schedule, design, and cost impact section; and,
• The signature lines.

The change order serves several important purposes at this point:

• The change order documents exactly what tasks you and your client have agreed to, which will invariably be forgotten in a few weeks as the project progresses.
• The change order emphasizes that these changes really were out-of-scope.
• The change order emphasizes your team's contribution to the project, and clarifies any additional funds that your client needs to invest.
• Your client will likely be impressed that you are so methodical in your approach, especially if she has never seen a change order before.

Figure 5-1 details a real change order we prepared for NeonTommy.com, a Drupal development project to create an online news portal.

Figure 5-1. A change order detailing refinements to NeonTommy.com

Negotiating Out-of-Scope Changes

If you do everything you can during the planning phase to manage the project team's expectations, document the project requirements, develop an appropriate budget, and allocate sufficient resources, the project should come in on time and on budget.

However, despite your best efforts, some aspects of the project can be interpreted differently by the client and consultant.

A Wretched Experience

We were building a custom web application that imported data on a nightly basis from the client's data management system, which we'll call WRETCHED. During the requirements gathering phase, we were told by the IT manager for WRETCHED that we would receive data in any format we specified. We priced the data import aspect of the project accordingly. However, during implementation of the project, the client's IT manager had moved on, and the new IT manager was only willing to export the data in the default system format. This change meant that instead of simply reading in the data file, we had to perform extensive preprocessing and data cleansing during the automated data import process. This effectively doubled the budget for this aspect of the project. From our perspective, this represented an out-of-scope change in the project. From the client's perspective, we had agreed to perform data import as part of the original project budget, and so it was in scope.

What did we do? We took a data sample from a similar project and a data sample from the client's WRETCHED data management system. To simplify the process for the client, we showed the client how one data set could be imported into Excel in a few steps. However, performing the same operation on the WRETCHED data set caused the import to fail. In the end, the client required her IT manager to provide data from WRETCHED in a standardized format or fund the additional work from the IT manager's budget.

Be Transparent

In our experience, the best approach is to be transparent and forthright about these issues when they emerge. Treating out-of-scope issues openly will ultimately build confidence with your client, as they realize that you are addressing matters head-on and not trying to just make them go away or cutting corners to get them done.

One of the recurring challenges with out-of-scope items is that the changes frequently come up throughout the course of a project. The temptation is to simply do the work, and move on. No one likes to disappoint a client by saying that something is out of scope. However, the better approach is to set aside tasks that you perceive to be out of scope, and tell the client that you will come back to that task at the end of the project. This way, you stay focused on completing the in-scope items on time and on budget.

As you near the end of the project, you will likely have a list (hopefully short) of out-of-scope items for discussion. However, by consolidating all of your out-of-scope items, you are in a stronger position to negotiate with your client.

Negotiating

Before you begin a conversation with your client, prepare a comprehensive list of all of the out-of-scope items that you have identified. Debating with your client about an 8-hour task on a $100K project might seem like you are nickel-and-diming your client. However, if you assemble a set of ten out-of-scope changes that represent 40 to 80 hours of additional work, this is a more sizable issue to discuss.

Addressing these issues with your client requires patience and finesse.

You might explain to the client that it is in your team's best interest to maintain a positive relationship with them so that you can continue to benefit from working together in the long term. However, your development team also needs to remain profitable in order to continue to provide the services to all of your clients.

• First, try to figure out what seems equitable to you, and what fits in your budget. For example, if you have 80 hours of out-of-scope items on a project, and you propose to complete only 4 hours of the work, that is not likely to go over well with your client. However, if you offer to complete 25% of the changes (20 hours), this might seem like a major concession to the client.
• You can either propose to take on those tasks that seem most important to you or you can let your client decide how to allocate those additional hours. If you let the client identify the top-priority tasks, you might be surprised to find that the items that you thought were most important to your client in the early part of the project actually turn out to be far less important by the end.
• You might also suggest that your client pay half the cost.
• Finally, you can suggest that any unresolved out-of-scope items can serve as the foundation for phase 2 of the project, which can begin as soon as phase 1 is done.

We find that this collaborative approach to negotiating out-of-scope changes works 90% of the time. The vast majority of clients understand that not all aspects of a project can be perfectly defined at the beginning—as anyone who has ever remodeled their kitchen or had their car repaired can attest.

What to Do in the Worst Case?

In the worst-case scenario, if your client simply refuses to negotiate and argues that all of the out-of-scope changes are, in fact, in scope, you have a difficult decision to make.

We find that conceding on the scope of work is a poor business decision. It leads your client to believe that they will always be able to push you to do extra work. Conceding the scope of work will also likely cause your project to be over budget. On the other hand, we take pride in leaving a project in the best possible state when we complete our work, and if there is still a lot of unbilled work, there may be considerable funds still on the table.

If you or your management team decide that you have to wind down the project at this point, we firmly believe that it is in your best interest to do this as gracefully and professionally as possible. First, meet with your team and explain the issue. Then, document the out-of-scope changes in a change order. Complete any remaining work, and let your client know that you have completed the current phase of the project and that you will need to wind down the project in an orderly manner at this point until the out-of-scope issues are negotiated. You can send along the change order and your project documentation. This act will signal to your client that you are acting professionally, despite the disagreement regarding the out-of-scope changes. This approach leaves the door open for future work or renegotiation.

Wrapping Up

Scheduling a project and managing out-of-scope client requests are vital to ensuring a successful project. You should now have a good sense of how manage these processes. In our next chapter, we look at how to overcome obstacles that often cause project delays.

We start off with the tale of an IT manager that fails to take ownership and subsequently loses control of resources. We then look at how to use a weekly checklist to maintain project momentum over the long weeks and months of a project. We wrap up the chapter by covering several techniques you can use to improve your interactions with and to facilitate the decision-making process of indecisive clients.