The Project Definition and Scope of Work

Before you have a project, you have a proposal. The project definition is vital because the proposal sets the tone for the entire life of the project. From our years of experience in advising clients on projects, we’ve developed the following simple approach to easily navigate the pre-project phase:

• What is the problem?
• Can we help solve the problem?
• Outlining the solution: the scope of work

Since the proposal is the first work product of yours that the client will see, it’s vital to set a great first impression. With this in mind, we also cover how to prepare client documents.

Finally, we cover how to address a common client concern during the project definition phase: What is customization and what is configuration?

What Is the Problem?

Many years ago, when Chris was gracefully leaving the employment of a long-time entrepreneur to start his own business, his employer told him that he would not succeed.

“You won't make it. You don't have what it takes to make it on your own. You need to be able to sell wool blankets at a Dodger game on a hot summer day.”

That remark hit Chris hard, especially coming from someone with whom he had worked for many years. But he also saw the fundamental difference in the way each of them would run a business.

He thought, “I won't sell blankets; I'll sell beer.”

Chris often recalls this conversation when meeting with a new client. He asks himself, am I trying to sell this client something that they don't need—the wool blanket on a hot day? So when our team first speaks with a prospective client about a project, we present ourselves as advisors. We don't start by trying to sell a product or service. Instead, we learn about the client, their business, their technology, and their specific technology problem.

Be a Trusted Advisor

First, be an advisor. This approach will pay off down the road. If you appear to be a cheerleader for a particular technology or approach, your client will never be able to heed your advice without wondering if you are trying to promote your favorite technology. If you begin the project with an objective evaluation of the various approaches or technologies, you present yourself as your client's advisor or advocate. This is a much stronger position than being a promoter of a specific technology.

Listen to what the client is telling you about his or her problem, and try to get to the root of that problem. Here is an example of how a conversation might start:

Client: “We need a better system to print letters thanking donors for their contributions.”

Consultant: “Why, what's wrong with the current system?”

Client: “It's too manual. We have to retype everything.”

Consultant: “What do you use to track your donors?”

Client: “We keep some of it in a spreadsheet, and some of it in files.”

If we had tried to solve this (admittedly simple) problem by recommending a system for printing letters, we would have committed ourselves to a specific technology without understanding the problem. The problem here is not about printing letters. That is a byproduct of the real problem: the lack of a customer relationship management system or database.

Here is another example of trying to use a one-solution-fits-all approach to problem solving. We know a highly technical and skilled colleague who is an expert with a programming language called Perl. When asked to complete a task or project, he will always use Perl. It does not matter if there is a better language or way to do the project; he knows Perl, and that is what he will use to solve the problem.

If we have a programming project for which Perl is a good choice, then he is an excellent fit. If we have a project where the requirements do not match what Perl offers, he is the wrong choice. He thinks anything could be done using Perl. But if Perl is not a good solution, you would not want him working on your project.

When you consider building a complex system or application, it is often unwise to select the system architecture and software based solely on the qualifications of a single person. Often, it is much better to evaluate several options and select the best fit.

Once we understand the client's problem, we usually offer three likely technology solutions, and present the pros and cons of each.

Be Honest. Really.

Being honest actually works very well. No one expects the project to go off perfectly. If you start the project by being honest about problems and concerns, you will be in a much stronger position to present problems as they arise during the course of the project.

If there is a less expensive way to do the project, identify it.

Client: “We're thinking about asking you to implement enterprise solution X to host and deliver streaming media from our web site.”

Consultant: “Hmm. That is a very good system, but it might be more than you need. Have you also considered option Y?”

Client: “No, I'm not familiar with option Y.”

Consultant: “Let's compare solutions X and Y, and see if Y might work you. It's about 10% of the cost of enterprise solution X.”

Client: “Great. Now we have plenty of budget to have you perform the evaluation.”

Beyond the obvious ethical argument, honesty helps build a precious resource that is easily lost and painfully gained: credibility. Credibility built at the start of the project—or even before it has begun—will help you manage the inevitable challenges you will face later in the project. Even when it hurts, it pays to be honest.

Can We Help Solve the Problem?

From time to time, when discussing a potential project with a prospective client, we realize that the solutions we could bring to the table are not the ideal options for the project. What do we do?

We discuss the most likely project options with the client, and then we tell the client that we are unlikely to be a good fit because we are not experts in the solutions that will best serve the project.

We are prepared to lose the business on that project. But, two surprising things often happen:

• The client hires us anyway. Many clients appreciate the value of having an honest advisor on the project, so they will hire us to help specify the project, hire a consultant, or provide project management oversight.
• The client hires us for another project. Most organizations have multiple projects. Although you or your company may not be a good fit for a particular project, the potential client is likely to remember your candor and engage you on a different project.

Like honesty, knowing when you are not a good fit for a project will help you build credibility. There is no short supply of vendors and partners ready to sell something to your client, but there is a shortage of honest people you can trust.

Outlining the Solution: The Scope of Work

If the client feels that we are a good fit the project, we're asked to prepare a scope of work.

Fundamentally, a scope of work is the statement about what you will do. Often, the scope of work includes a budget or expected level of effort. The scope of work sets the bounds on what will be included in the project, and importantly what will not be included in the project.

Scopes of work take many shapes, but the best of them have common elements. Your scope of work should almost always include the following:

Project Name

This is often an overlooked opportunity. Create an appealing and useful name that adds weight to the project. For example, “Admissions Database” is fine, but boring. Try changing the name slightly to “Admissions Database for Applicant Management,” or “ADAM.” Now the project has a catchy name, one that makes it seem more human, approachable, and manageable.

Contacts

Include the name and contacts of the project sponsor for whom you are preparing the scope of work as well as your own name and contact information.

Date and Version

A scope of work may go through several iterations before it is accepted. Add a date and the version of the scope of work so you know which version is current.

Background

Add a few sentences about the high-level business need for the project, as well as how it originated and other background information. While this information may be obvious to you and the project sponsor, you should be aware that a scope of work is often distributed well beyond the immediate project audience; for example, we know of a scope of work for a small web application development project that ultimately reached the CEO of a Fortune 500 company. This background clarifies the usefulness of the project to someone who is not familiar with the project.

Scope of Work

This is the essence of the project. Identify the different components or phases of the project separately. For example:

• Discovery and planning
• System architecture design
• Visual design

When we first started writing scopes, we would include one or more paragraphs about each project component. After observing how people tend to read scopes of work, however, we changed the way we prepare them. Typically, we try to include a brief set of bullet points that clearly define the work that will be performed and the products that will result from each step.

For example:

Discovery and planning

• Conduct a series of three kickoff meetings to identify requirements.
• Prepare a requirements document.
• Create the application home page wireframe.
• Create five wireframes of key functional pages.
• Update the project budget, if necessary.

In most cases, the project starts with an initial discovery and planning process (read more about this in Chapter 4). Clearly defining the steps you will use in each phase of the project and the specific deliverables helps set the client's expectations and limits what you will need to provide at each stage of the project.

This approach also makes it much easier to estimate an initial project budget. For example, it is very difficult to identify accurately how much time is required for discovery and planning, which encompasses many steps. If you break this down into discrete tasks, it is much easier to determine the time required for each component and to total these individual costs to arrive at a budget.

For example, instead of including a huge item like “development” that includes everything from design through launch, break up the scope and budget into smaller pieces that describe specific tasks included in development, such as

• Interface Theming
• Installation and Configuration
• Application Development
• Quality Assurance
• Testing and Beta Testing
• Launch

Timeline

Timelines will vary widely depending on the size of the project and the number of constituents. However, we find it helpful to prepare a generalized schedule as a starting point for discussion with the client. This schedule can typically be a simple Excel chart with five or six key milestones that correspond to key tasks in your scope of work. We usually include the following statement with the schedule:

“The project manager will update the project schedule upon completion of the discovery and planning phase of the project when the full project details are known.”

This helps you define a general schedule while allowing you to defer building a detailed schedule until you have more information about the project.

Investment Budget

This is probably the first section that most people will turn to when looking at a scope of work. The investment budget section typically reduces the entire scope of work to an easily readable chart that includes each of the steps and the amount of time involved.

In many cases, your budget will be higher than what your sponsor expects. (Development is hard work!) If so, it helps to separate the optional tasks from the required tasks. You can do this easily by creating two budget sections: core project budget and optional project budget. This way, the project sponsor or client can immediately identify which aspects of the project can be moved into a later phase without disrupting the entire project.

This also helps to avoid having to answer questions like, “Can we move the discovery and planning task to phase 2?” Obviously the discovery phase must come before—not after—the start of the project because by definition, it's discovery.

Approval

Even in informal or internal scopes of work, include an approval section with signature blocks for the project manager or representative of the company, as well as the project sponsor or client. There is a psychological difference between verbally agreeing to proceed on a project and actually having to put your signature and name on a scope of work.

The scope of work should never be a replacement for a formal contract for services between an organization and a consultant. A contract protects both the consultant and the organization paying for the project in the unfortunate case where the project does not work out as intended and needs to be terminated, or in cases where the sponsoring organization needs to terminate the project due to budget or other considerations.

Don't Go Chasing Methodologies

Before going any further, we want to mention that this book is not about a specific methodology. If a project is poorly managed, it is at risk of failure regardless of whether Agile or Waterfall methodologies are used. We don't have a methodology to sell you. We have a project to complete on schedule, on budget, and according to your expectations. If anything, we advocate a pragmatic approach to the use of methodologies.

If you work in a larger organization that has a well-defined project management process, you may have little choice about which methodology your organization will use. However, for many project managers in web application projects, little thought is given to which, if any, methodology will be used. There are loads of software development methodologies floating around these days. Two of them seem to be exceptionally popular at present.

In the Agile software development methodology, teams work in short spurts building just a few features at a time, test and refine often, and gather feedback from the client frequently. Proponents of the Agile method argue that this helps to ensure client satisfaction as they are involved with the project from the start, and development can't drift away from what the client wanted.

The polar opposite of Agile development is the Waterfall approach, wherein you move from one defined step of the project to the next in a deliberate and orderly way.

Because the Agile approach includes so much more feedback from the client than the Waterfall approach, Agile development is often considered client-driven.

Several popular businesses are outspoken about this approach, and so the Agile methodology is often perceived as hot and young, while the Waterfall methodology is seen as stuffy and old. Think Facebook (hot, young, and exciting) vs. IBM (staid, fatherly, and predictable).

Hype and popularity are not valuable measures of the merits of a technology.

Still, you will find that the approach we advocate in this guide is oriented more toward Waterfall.

Here are some pros and cons of each style based on our experiences:

Agile Methodology

Pros

• Fast ramp-up. If you have a tight timeline and a team ready to go, an Agile process can get you started developing an interim product within a few days of the project start.
• Immediate results. Agile focuses on providing immediately useful components during each sprint. If your project will benefit from being able to interact with and test drive the system quickly, Agile can work well for you.

Cons

• Client expertise. In a client-driven consulting process, Agile assumes that the client possesses expertise in areas that would be useful throughout development. If this is not the case, and the client is not technologically sophisticated, inconsistent or undirected feedback can hurt the project. Getting feedback from someone never involved in a web project before—let alone a consulting engagement—could prove to be a disaster.
• Project delays are highly disruptive. In our experience, many small and midsize projects are spread over long periods, and team members focus intermittently on the project in short bursts of time. In this case, if Agile is used, you can burn through your project budget quickly without achieving your project goals.

Waterfall Methodology

Pros

• More structure. The Waterfall methodology often provides a more structured approach to uncovering requirements at the beginning of a project. If the project has interrelated complex requirements and needs to be developed as a complete package, Waterfall tends to work best.
• Manages expectations. Using a well-defined Waterfall process can help manage the expectations of the client. You make it clear when feedback will be collected and include time to act on that feedback, make refinements, and respond to your client's concerns.

Cons

• Changing requirements. Since there is a defined lag in time between approval of project requirements and the client's first review, it's possible that new requirements have been identified or priorities have changed. In Waterfall, these are hard to address.
• Planning time. If you use Waterfall, you will spend significantly more time in project planning at the beginning of a project. This contrasts with Agile, in which the client and developer uncover requirements as the team proceeds with the project.
• Less real-time feedback. Typically, there are longer intervals between client feedback on a project managed using Waterfall than on a project managed using Agile. Some project managers mitigate this concern by demonstrating to the client incremental features or having guided “walk-throughs” of selected features of the application.

The Document Formats Rule

There are really three document formats:

• Formal, for documents like a scope of work or a requirements document;
• Informal, for a recommendations document or technology research summary; and
• E-mail, for everything else.

A formal document should have your logo, a nicely formatted footer at the bottom of the page, and a cover page with the client's name, project name, client contact, document date, and a document reference code.

Use this format for proposals, scopes, and requirement documents (where you do formal requirements gathering). But do not overuse this format. For example, if you are preparing a list of recommendations for server and site improvements on a project you are now supporting but did not build, the informal format will work fine.

The informal format is great for documents that are too long for e-mail but do not need the logo, branding, and client information. Still, these should have a simple footer with a page number and the document title.

Preparing Client-Ready Documents

Whether it is a requirements document, a scope of work, a list of recommendations, or a feature request list, documents sent to the client must be treated with care. Like it or not, the content of your e-mails and documents largely shapes the client's opinion of you. That is why a spelling mistake in an e-mail is so embarrassing—or should be. (See the “Tips for Writing E-mails” section in Chapter 8 for more information.)

Still, it can be painless to prepare client-ready documents. Follow these guidelines:

Send PDFs

Do not send documents in an editable format unless you specifically want the client to edit a document, which should happen infrequently. As a PDF, it looks more finished and works on any operating system or device.

Hand-Edit Your Document

The best way to edit a document is by hand. When you feel the document is complete on the computer, print out a copy, push your mouse and keyboard away, grab a pen, and edit the entire document, start to finish. When you find errors, mark them on paper—avoid jumping to the computer to fix them.

You will catch more errors and the prose will read much better after a hand edit. Just try it.

Double-Check the Attachment

When you send the document to your client, open the file you attached to the e-mail and briefly look it over. You will often catch overlooked errors this way; for example, when you finished editing you might have changed the orientation to landscape, resulting in an incorrect alignment of the page numbers in the footer. Then there are the Friday afternoon errors, like attaching the wrong file.

Configuration vs. Customization

These two words sound similar enough. However, they can imply a huge difference in your project's budget, level of effort, and timeline.

We find that when a current or potential client with a limited budget begins to outline ambitious plans for a project, explaining the difference between these two options can be useful.

In the simplest form, from a technical perspective, customization requires changing source code, while configuration does not.

Let's dig into the differences a little more deeply.

Configuring Software

You modify the software using the software's standard interface. For example, if you were using a web content management system, configuring the software would be completed using the web interface. Most good web-based software today is highly configurable, enabling you to shape the behavior of the software.

Customizing Software

You modify the code that powers the software. Customization can increase the cost and complexity of a project dramatically:

• You need a developer or engineer who understands the software and programming language well enough to perform the modifications.
• You have to test the modifications you have made to the software to evaluate how they will work with other parts of the software. If your customizations are extensive or if the software is very complex, testing can be at least as challenging as the customizations themselves.
• You have to maintain the customization to the software. When new versions of the software are updated, you will need to carry your customizations forward. Maintaining customization requires you to have good documentation, a system to manage your code, and a developer who has expertise with the software.

  Some types of software plan for customization and provide architecture to support it. For example, the open source web content management system, Drupal, provides a modular architecture in which you can write your own custom modules that interact with the software. When it comes time to upgrade, you know that all your code customizations are retained in a specific custom module.

• Customization projects tend to create consultant lock-in, as those who make custom refinements are the experts on how to maintain them.
• Finally, if you customize your software, future development and maintenance will cost more. For example, when we come into a project where there has been a lot of customization (particularly if this customization took place over a span of a year or more and with several developers), we expect that there will be a variety of problems with the testing, code, or documentation.

Despite the challenges, however, there are compelling reasons to customize software:

• Customizing software is typically far less expensive than writing new software. If an open source software product provides you with 75% of the functionality you need, customizing the software is likely to be significantly less expensive than writing new software from scratch.
• Why? Let's say you decide to rewrite an open source solution that provides 75% of what you need. You only have to do the work to recreate that 75%, right? Wrong. You will also need to fix all of the bugs and architectural issues that will naturally be introduced in the process of rewriting that code. Like it or not, more time is spent fixing bugs than writing software.
• From a marketing perspective, if you are supporting your products anyway, “customization” can make a nontechnical client feel good. People tend to like the idea of customizing—think about customizing your car, bike, wardrobe, and so forth. You offer your client the sense that he is special and you are building something just for him.

Cost Implications

When a client or potential client understands the difference between customization and configuration, she appreciates the features that may be required in the two types of software. She is much more understanding of the budget involved when the project requires customization.

Tactically, these cost implications can be used to help clients be sure that the incremental value they receive from a customization matches the cost. Some clients will ask for expensive customizations, but fail to notice that, of their requested customizations, two out of three were nice-to-haves, whereas one was worth many, many times its cost.

Wrapping Up

By this stage in your negotiations you should have a good general sense of what problem the client faces and whether you are a good fit to help address it. You should have all the tools necessary to write a great proposal. The next stage in the process—discovery and requirements—is to detail all of the specific features and functions of the project. We cover this in Chapter 4.

However, before we dive into discovery and requirements, we will spend the next chapter looking at a vital project management activity that occurs at all stages of the project process: meetings.

If project management is three things, it's about managing your team, your client, and your boss. It's in meetings where a lot of that “people management” happens. Bad meetings can be boring, unproductive, and inefficient. They can also put projects at risk if the client loses confidence in your ability to lead the project. Running a great meeting is vital to project management.

In the next chapter, we tell you about a disastrous meeting one of your authors attended and we give you real tips and tricks you can use to run efficient meetings that don't bore and do build client confidence. Read on!