Running the Project

The Blindsided IT Manager

Todd is the IT manager for a department of 150 people within a Fortune 1,000 company. Like many IT managers, Todd feels that he and his five-member team are overworked, underappreciated, and underpaid, all of which might well be true. Todd is responsible for all IT purchases and projects in his department.

Three months ago, he was called into a meeting with one of the division directors (one of several bosses to whom Todd reports), and was asked to provide technical leadership on a new web-based application being worked on by another team of five staff members. The project had been approved by management to help track customers more efficiently. At the end of the meeting, Todd agreed to help define the project specifications and determine if the application should be hosted in-house or outsourced.

Of course, many more urgent projects had come up since then, and the customer-tracking system had been pushed down on his list. Although Todd had been quick to answer a few random questions from the project team via e-mail last month, he never found the time to schedule a follow-up meeting. In fact, the project sounded quite open-ended, so Todd was not entirely sure where to start. The lack of project definition made it easy for Todd to keep pushing this project down on his list.

Today, Todd was asked to attend a second project meeting. Expecting to be asked some technical questions, he reviewed the previous meeting agenda and his notes, and printed out the pricing for an online customer relationship management system he had heard positive things about at a recent technology conference.

During the meeting with the customer tracking team and the division manager, Todd feels blindsided as the team informs him that they have hired a consultant to develop the system and have already acquired the hardware. Todd will be responsible for getting the hardware set up in the division's data center and for supporting the hardware.

Todd is both embarrassed and angry. He had no warning that the team was moving forward without his advice. Further, the hardware that had been purchased was different from the type that Todd's division typically supported. Also, Todd noted defensively, the operating system and platform specified by the consultant would be totally new to the division, and he did not have anyone to support this system.

Todd is understandably upset, and he becomes increasingly defensive during the meeting. He knows from previous experience how to throw up techie-sounding roadblocks to a project, such as concerns about the scalability of a database technology. However, the team and the division director are patient and persistent. They offer to outsource the project hosting to the consultant and suggest that Todd can pay the hosting fees out of his IT budget.

By the time the meeting is over, Todd recognizes that he has lost control of this project. He had no idea that this project was so important and needed to move quickly, but he still finds it unconscionable that his director would move ahead without his advice. Todd decides that the best he can do now is provide the bare minimum support that has been requested of him while focusing his energies on more important and interesting projects.

Todd's biggest mistake was that he didn't take control of the situation after the initial project meeting. In the first meeting the leadership made it clear the project had funding and support and was moving ahead. At this point, Todd could have exerted more control over the destiny of his department by taking the lead on defining the project and hosting requirements.

His inaction left a vacuum of power that by necessity had to be filled by another person. It's unfortunate that others decided Todd's fate without consulting him, but by abdicating responsibility he is largely to blame. Indeed, had Todd spent a few moments after the initial meeting to think through what might happen, he may have guessed that losing control of his resources was a real risk and could have acted to stop that from happening.

In this chapter, we will introduce a series of techniques you can use to maintain project momentum, force answers from reluctant clients, and anticipate problems before they happen.

Maintaining Project Momentum

Momentum is critical in running a project. One reason projects slow down or stall is a lack of consistently applied attention to the project. It is easy to let a day go by when you do not move a project forward. The problem is that those days stack up because every additional day you do not give a project the attention that is needed, it gets easier to neglect. Before you know it, it has been weeks, work is piling up, and the real schedule for the project is behind.

The key to overcoming this challenge is applying momentum. We have two techniques for maintaining project momentum: one-a-day productivity and the Monday morning checklist.

Technique #1: One-a-day Productivity

The idea is simple: no matter how big the task or how many work hours it might take, simply complete one modest but measurable task each day that brings you one step closer to project completion. This task can be anything; just ensure that it is easy to quantify as a single unit of work. Maybe it is adding five testing checklist items to your quality assurance document, or quality assurance testing and verifying one new feature the developers completed. It does not matter, as long as it is one unit of work that brings you one step closer to completion.

When you start, it might seem like doing one modest unit of work will never have any impact on the massive task that is your project. But the old clichés—about how a journey is really just 10,000 steps, or how you can move a mountain by yourself if you are patient and move just one pebble each and every day—are true.

Take a recent personal project: Justin recently converted his modest DVD collection (about 250 discs). Digitizing a DVD does not take much effort—you put the DVD in the drive and click a few times on your computer—but you can only do one DVD at a time, and it takes your computer several hours to extract and transcode the movie to a computer-friendly video format. This was not a job he could knock out on a productive Saturday.

For several weeks, no DVDs got encoded. Why bother with one when there are so many to do? There is no hope!

Justin came up with a simple rule: encode one DVD a day. He was hesitant at first, as basic math shows this approach would take the better part of a year, but he persisted. Something funny happened right away. The easily attainable daily goal provided frequent motivation to “overachieve” and encode two or three DVDs per day. The DVDs got encoded in 3 months, and the daunting project went from overwhelming to complete.

When working on a project, a one-a-day approach fits in nicely with situations like working down a pile of bug fixes that need testing, verification, and review. A stack of 30 to 40 bug fixes is probably too much to do in a day, but if you set a goal of testing and verifying just two or three bugs a day, you can work down this list with speed. Or, set a goal to review one completed feature per day on a large project so that completed features from your developers do not overwhelm your Inbox.

The goal is simple: Doing several modest tasks consistently each day or week translates into a lot of progress over time.

Technique #2: The Monday Morning Checklist

The Monday morning checklist is likewise simple: it is merely a short list of tasks you complete each and every Monday morning. Why Monday? Monday is the best time to plan your and your team's priorities for the upcoming week. By identifying issues on Monday, you can allocate resources during the rest of the week to address those issues and solve any problems.

Monday is also the best time to look at the week's calendar and make sure that you are prepped and ready for upcoming meetings. (For all the same reasons, Monday is the best day to have individual team member meetings with your programmers, testers, designers, etc. Completing the checklist before these meetings is even better: you will have a good sense of where things stand and can set priorities for your team for the week.)

Justin first used the Monday morning checklist for a rather large project that lasted several months. The checklist itself was straightforward and included items such as the following:

• Are there any outstanding client action items that need follow-up?
• Are there any meetings this week that need prep?
• Review any completed features.
• Review and update the project schedule.

In all, there were about a dozen items that he could run through in under 1 hour. He ran through this checklist every Monday morning, and several benefits became clear:

• Meeting reminders went out and agendas were always ready for any upcoming meetings that week. There were no surprises, and the team was always prepared for meetings with the client.
• Any threats to the project schedule became apparent early.
• Feature review work did not pile up.
• Deliverables from the client were more consistently forthcoming (due to polite but persistent nagging).

The checklist forced him to prod the project forward each week and to keep chipping away in little pieces at the mountain of work it contained to keep the project moving forward.

It is likely you will have several smaller projects on your plate at any time, so you do not need a checklist for each one. In fact, the simpler your checklist, the better. Try putting together a single checklist that you run through each Monday that includes items for all of your ongoing projects.

Here are few tips for putting together a Monday morning checklist:

• Keep your checklist short. You need to complete this on Monday, a day when unexpected work tends to appear more frequently than the rest of the week. Include no more than 12 to 15 items.
• To reduce the chance you will gloss over a task, try to keep each checklist item specific and achievable. Do not include anything nebulous; only items with a clear path to completion belong on the checklist. You want to feel good after completing each one.
• Print it out, if possible. For whatever reason, crossing out items with a pen feels good. It is also harder to ignore a paper on your desk than a task item in Microsoft Outlook.

As an example, here is a Monday morning checklist Justin has been using recently (some specifics removed):

• Verify system administration checklist was completed last week. Review for any problems.
• Check on any past-due tickets.
• Review status of support tasks for {support project 1}, {support project 2}, {support project 3}.
• Schedule sanity checks. (In this context a sanity check is a checklist of things to review on a web application, such as server configuration, reviewing the log files, and targeting quality assurance tests.)
• Review billing report.
• Monthly: Send monthly summary to {client}.
• Review project schedule for {major project}.

Put Yourself in Your Client's Shoes

It's a powerful yet simple way to do good work: put yourself in your client's shoes. Most people do not do this—or think to do it—because our brains are not wired for it. But it is easy. When you are finished writing an e-mail but have not sent it, take your hands off the keyboard, take a deep breath and think, “OK, I'm the client. How does this read?”

You can also do this with the help of a colleague. I call it playing the devil's advocate.

Grab a colleague and say, “OK, I want you to be {client name}. Read this. What are your biggest concerns?” Guessing what people think is a fuzzy art. You will never be 100% accurate, but just the act of putting yourself in their shoes will work wonders for your perspective.

It is a great way to make sure you send decent e-mails. Try it for a week, and I promise that by Friday, you can look in your Sent box and notice the difference.

Proactive Project Management

From our experience, if clients are not responsive, their projects are behind schedule.

E-mails are an example. Responsive clients answer your e-mails quickly. They are probably the same clients that are easy to work with because they are comfortable making decisions.

By contrast, unresponsive clients do not make decisions, reply to your e-mails, answer your questions, or offer feedback. So, how can we persuade these clients to respond on their own initiative?

You cannot. There just is not a way to do this. That is where proactive project management comes in. Proactive management forces the client to decide. You tell the client you have evaluated an option and state very clearly that you will proceed with your option unless you hear back otherwise from him by a set deadline.

Here is a sample e-mail:

Hi {client name},

I'm happy to report that development of the new survey is going well. However, an issue has come up that I need your help with.

We currently have the survey spread across 4 pages, as you outlined in your document. However, the questions on the third page of the survey are really short so the page looks out of place. I suggest we combine the questions from pages 2 and 3 and shorten the survey to just 3 pages (page 4 becomes 3).

If I don't hear back from you by Friday I'll assume this works and we will proceed.

Thanks,
{call sign}

This approach is so very simple and so very effective because the client must decide whether to

• Not say anything, allowing you to proceed when you want and how you want;
• Give you a decision by your deadline so you can proceed; or,
• Say, “Hold on.”

In our experience, option 3 happens rarely. Most of the time, the client will be silent, the project can proceed, and you can stay on time.

This is not a strategy to use on all clients, but it is helpful for many of them.

What Defensive Driving Teaches Us About Project Management

When Justin was a teenager and learning to drive, his mother offered him a single piece of very valuable advice: “Always assume everyone on the road is about to hit you. Look around at the cars and imagine ways that could happen. And then imagine what you would do to avoid it. That way, you can actively work to avoid it happening and be ready if it does.”

This advice helps you drive more safely. When you think about the danger that other drivers pose, you start to develop safe driving habits; for example, looking in your mirror and deciding whether you have the clearance to suddenly stop or swerve to avoid something. In fast-moving cars, every second matters.

Project management may not be as fast-paced as driving, but the principle is the same. And this does not just apply to projects. It is the same advice that can help make everyone from butlers to chiefs of staff effective: try to plan for what is likely to occur and be ready for it before it happens. Whether being ready means making a cup of hot tea before being asked or having read a brief for a topic that might come up during a meeting, the result is the same: you are better able to handle a situation when you are prepared than when you are not.

In project management, being defensive means identifying what is likely to go wrong during and toward the end of the project. This is probably the original reason that all big project management tomes talk about creating massive risk assessment reports for documenting in detail all of the challenges a project might face (a veritable sea of pages and numbered outlines and indents and footnotes). But the problem with huge documents is just that: who has time to read a huge document?

You do not need to create a risk assessment document for your projects. However, you will benefit from taking a moment at the start of the project—and throughout—to think, “What is the biggest risk here, and what can I do right now to protect myself against it?”

• Try imagining what each of the stakeholders is going to say when you show them the finished project; not just your client sponsor, but the actual people who attend most of the meetings during the course of the project. These people are the driving force behind key features and sections. How do they think? Did they have a pet feature that did not fall within the scope?
• Try thinking about where in the project the client might want changes. This is probably going to be in one of the more complex features in the project.
• Try thinking back to previous similar projects, and recall what the main challenges were. Do any past lessons apply here?
• Were there any team members during requirements gathering and early scope discussions who proposed features that his or her internal organization ultimately decided against? This team member could feel resentment, which could poison their feedback and attitude in later phases of the project.

Hope for the best, prepare for the worst. Be defensive in your planning (but never in your composure to the client). Know that there will be some issue at the end of the project that you need to take care of, and make sure you have the capacity to do it. You have nothing to lose by planning ahead to handle an eventuality that has a real chance of coming to pass.

Planning ahead serves the interest of the client as much as it does the project manager and the firm for which you work; your project team will be ready to handle the situation, and the client's budget will be protected as well.

Quick Tips for Getting Work from Clients

Given that many clients tend to juggle lots of different projects simultaneously and with various different stakeholders (you are likely to be just one of many), it is sometimes hard to get the decisions and work product you need from your clients to move your project forward.

Here are some quick pointers to help mitigate this challenge:

• Use proactive project management (see “Proactive Project Management” earlier in this chapter).
• Do not be afraid to send a polite reminder to clients who have outstanding action item deliverables (see “Meeting Wrap-Up” in Chapter 3).
• Make deadlines and any delays to the schedule clear to the client in a polite way. When a deadline approaches, send a polite reminder that the project is going to be delayed if a deliverable or decision is not provided.

Be willing to accept a project delay from a client, but clearly state that the budget will be impacted to restart a project. Hopefully, your contract clearly states that restarting a project after a delay of a specific timeframe will incur project restart fees. If it does, you can gently mention that you really want to avoid having to put the project on hold and incurring those fees.

Wrapping Up

Maintaining project momentum is a major responsibility of any project manager. It's at the heart of what a project manager is meant to do: clear obstacles so others may get work done. Projects large and small need continual attention to move forward, step by step, toward a goal. Even if the step is small, the contribution to momentum is real. With what you've learned thus far, you now have a variety of techniques in your arsenal to address situations in your projects that can impact momentum.

In the next chapter, we look at an important step in the project planning process: the technical documentation. Where the requirements document outlines every feature that your project will contain, technical documentation details how each of those features will be implemented by your engineering team. While not every project needs technical documentation—and their length and density can often lead them to being underutilized—in preparing technical documentation you will encounter many of the technology challenges you would have encountered during development while still in planning.

As we have said many times already (and will continue to say), the earlier you are aware of the problem, the more cheaply (in hours or dollars) that problem can be addressed. Read on for guidance on when and how to write technical documentation.