N S I I

One challenge in leading teams is keeping people focused on the same goals for long periods of time. All leaders fear that decisions they make won’t be remembered. It’s possible that the reasons people had for listening to them today will be forgotten or ignored tomorrow. Perhaps worse, managers themselves may forget which direction they are supposed to be leading the project in. So, the challenge of project management is not only to get things started in the right direction, but also to keep it headed that way.

Chapter 3 included a brief overview of planning documents, such as MRD, vision, and specification. This chapter will focus in on the vision document, the most important of all early planning materials. I’ll explain why vision documents are worth the effort to write, what qualities good ones have, and how to continually get value from them over the course of a project. When they are used properly, they conclude the initial planning phase of a project (see Figure 4-1).

But one note before I start. There are many different ways to divide the ground that MRDs, visions, and specifications cover. Some organizations don’t use MRDs or business justification documents at all, and instead roll that information into the vision document itself. I’ve seen other teams divide what I call the vision document into four or five smaller documents and give them fancy names. A few times I’ve been on very small projects where vision-type information was collapsed down into the specification itself. So, don’t worry about how many documents you should have or what they’re called: I don’t think that’s particularly important. The advice that follows should apply well to any planning process you choose to use.

Taken From:The Art Of Project Management

Different projects demand different approaches to planning.

How planning is done is often determined by who has what authority. Requirements, design, and budget are the three kinds of project authority that impact planning.

There are some common deliverables for planning projects: marketing requirements documents (MRDs), vision/scope documents, specifications, and work breakdown structures (WBSs).

The most powerful way to plan a project involves use of three equal perspectives: business, technology, and customer. The customer perspective is often the most misunderstood and misused.

Asking questions forces good thinking and directs planning energy effectively.

The process of defining requirements is difficult, but there are good references for how to do it well.

Problem statements and scenarios are a simple way to define and communicate requirements. They are easily converted into design ideas without losing clarity about what’s important and what isn’t.

Taken From:The Art Of Project Management

With a list of potential features that grew out of user research, additional features to satisfy business or technology considerations can be added. But a primary question must be answered: what is the purpose of these additional requests if they do not contribute toward helping customers? Before adding new features, the existing list should be reviewed to see which ones already represent these business and technology considerations. This forces all discussion to be centered on customer impact and benefit, without prohibiting specific technology or business considerations.

It’s entirely possible that business requirements to exploit certain market opportunities are represented by one or more features already on the list. Technology requirements should also be tied back to benefits that those engineering efforts will create for customers. Any business or technology requirements that don’t connect with customer benefits (short or long term) should be scrutinized. These noncustomer-centric features should be carefully defined to make sure they do not negatively impact the customer’s experience.

And even if marketing demands an addition that has no ties to improving the customer experience, everyone will know that this is the case and respond accordingly. Sometimes, it’s necessary to add a feature to help sell a product, despite its dubious end-user value, or to satisfy a demanding client or executive. But by organizing the planning process first around customer research, problem statements, and resulting features, everyone will have to make arguments within that context. Warning bells should go off if the majority of features in a release have no direct connection to the customer. If they can be reviewed by their relationship to a customer-centric list, random or self-serving requests will stand out to everyone in the room and demand additional debate and discussion. This gives the project manager every opportunity to define a level playing field of features that has the best interests of both the customer and the organization in mind.

Taken From:The Art Of Project Management

Possible features of Project X:

Commonly used items will be easy to locate on the home page.

Search results will be easy for most users to read quickly.

The site will provide easy, automated access to HR services.

The registration page will make it easy to enter information without mistakes.

Department information pages will be at least as fast as the home page itself.

The database query interface will be as reliable as other parts of the system.

Users will be able to learn about email server status issues in a simple and convenient way.

Users will have a convenient way for the system to remember their preferences.

Feature statements should never describe a specific solution or design, but should instead explain the solution’s impact on the customer. (This is easier said than done. Most engineers and creative people love to solve problems. If you describe a problem, they’ll want to jump right into solving it instead of spending time trying to elaborate on or refine the problem. It’s common to require a temporary ban on solution proposals during discussions of problem lists and scenarios. Simply ask people to write down their ideas during the meeting, and then discuss them later. Make exceptions for ideas that completely eliminate problems from the lists or identify them as trivial.)

By postponing deep discussion about design alternatives, the team can focus on clarifying the real goals of the project. These feature statements can be ordered roughly by importance, helping to define the shape of what the project will be. If this is managed well, when the time comes to explore and define designs, it will go much faster because everyone will be working toward the same results (instead of being distracted by technologies or their favorite ideas for solutions). Because so much is riding on these short descriptions, they need to be written carefully and with consideration for how long they’ll be used by the project team. It often takes several passes and reviews to get them right, but once complete, they’ll rarely need to be redefined over the course of a project.

Taken From:The Art Of Project Management

Because problem statements represent the current state of the world, a project needs something else to express how the world will be when the work is completed. For this purpose, problem statements need to be converted into what are called feature statements or scenarios. There are many different ways to do this; use-cases are one popular method (see Alistair Cockburn’s Writing Effective Use Cases, Addison Wesley, 2000), but there are many others.

Each scenario is a short description of something a customer will be able to do as a result of the project, or the tasks they will no longer have to do because the project automates those tasks for them. The idea is to describe these things from the customer or user’s perspective and to avoid any description of how these benefits will be achievedthat comes later. For now, what’s important is that the team is able to articulate and discuss which scenarios have the most value. Considerations for the business value of solving each scenario or their technological feasibility should be reflected in how the scenarios are prioritized.

The feature statements themselves should become the way to most easily represent what’s been learned about customers and what the project will be focused on providing for them. Based on the previous list of customer issues, here is what some feature statements might look like.

Taken From:The Art Of Project Management

It sounds exciting to modify your beloved car. You may set up several interesting accessories that are being popular today. In fact, there are lots of choices with respect to car accessories as a car has some integrated parts ranging from lamp to wheel. When you are interested in getting the latest trend of auto accessories, there are online stores wherein wide range of the accessories available.

Carid.Com is an online provider, through which you will get your best auto accessories. This web specializes in car and truck accessories. Please check out all pictures of the product to get better overview. What kinds of accessories available in this web? There are dash kits, floor mats, chrome accessories and so forth. It’s an advantage to get some popular accessories such as projector head lights, LED Tail lights and lots more. When you need assistance, this web provides live support via chat online. Communicate any things you want to know in regard to this web’s products.

You may select types of car accessory based on brands. If you want accessories for your BMW, you need not to worry that this web has the most interesting for you. Other brands like Aston Martin, Cadillac, Ford and many more are also available.

As an example, here’s what a list of problem statements for an intranet web site might look like:

It is hard to find commonly needed items on the home page.

Pages with department information are very slow to load and users have to wait.

The database query page crashes when working with large tables, and users have to start over with their work.

The site does not provide automated access to HR services, which are time consuming to do manually.

Search results are difficult to scan with the current layout.

The registration page doesn’t warn about required fields, and it’s too easy to make mistakes.

The status page doesn’t include information about email, and users cannot find out why their email isn’t working.

There is no way to save preferences or options for how the home page is displayed.

Note that these are not bug reports. These issues may have never been identified as things the web site needed to do. Problem statements should be broader than and different in perspective from bugs because the idea is to capture what’s missing from the customer’s perspective, instead of only what is broken from a technical perspective.

Each of these one-sentence statements can be followed by supporting evidence or examples (say, screenshots from the web site or product that provides context for the issue, or references to the usability study or other research that surfaced the problem) to help tell the story and explain why and how the issue occurs (or why the omission of a kind of functionality is significant). But this supporting evidence should not mix with the problem statement itself, or with engineering plans or business objectives. For sanity, these customer problem statements should remain purely about customers and their needs.

Taken From:The Art Of Project Management

There are established methods for developing and documenting requirements, and I recommend familiarizing yourself with them (see the excellent Exploring Requirements: Quality Before Design, by Donald Gause and Gerald Weinberg, Dorset House, 1989). Depending on what authority you have over the requirements process, there are different ways to go about doing it so that you’ll obtain good results. The details of these methods and how to apply them are out of the scope of this book. However, I can offer you one simple method that I think is easy to use and generally very effective: the problem statements method.

Problem statements are one- or two-sentence descriptions of specific end user or customer issues. They should be derived from any of the research that was performed or from specific customer requests. They should be written in a format that identifies a problem or need from the customer perspective (as opposed to the engineering or business perspective). This will ensure that the point of view of the impact on the customer is maintained and not unintentionally distorted by other perspectives. Problem statements also help avoid some of the common requirements mistakes that teams make (we’ll cover them briefly in Chapter 5).

Taken From:The Art Of Project Management

Planning creates large amounts of interesting information (asking many questions tends to make that happen). The challenge becomes how to simplify the information and convert it into a form useful for defining a plan of action. At a high level, a vision document is where all of the perspectives, research, and strategy are synthesized together. We’ll talk more about that special document in the next chapter. But at a medium to low level, the simplest tool is the use of requirements. Vision documents often contain requirements information, but depending on whether specifications or other, more focused documents will be written, detailed requirements might be contained elsewhere.

Many projects use the requirements as the way to define the direction of a project. A requirement by definition is anything the team (and client) agrees will be satisfied when the project is completed. In the simplest sense, ordering a pepperoni pizza is an act of requirements definition. You are telling the pizza chef specifically what you want. He may ask you questions to clarify the requirement (”Do you want a soda with that?”), or he may negotiate the details of the requirement (”We’re out of pepperoni, will you accept salami instead?”). In the more complex case of software development, good requirements are difficult to obtain. There are many different ways to interpret abstract ideas (”make it run fast” or “make it crash less often”), and the process of eliciting requirements can be difficult.

Taken From:The Art Of Project Management

Experts at customer research do two things: they choose the method based on the questions the project team needs to answer, and they make use of multiple methods to counteract the limitations and biases of individual approaches. Table 3-2 outlines some of the major research methods and their high-level tradeoffs.

As a program manager at Microsoft, on the best project teams I worked on, I had access to many of these sources of information. I’d often have to request answers to specific questions that went beyond what I was provided with, but there were dedicated experts in the organization who would generally do this for me. On other teams with less support, I’d have to go and make do on my own (typically with less success because I had many other things to do as well, and I wasn’t as proficient at getting results as a full-time expert would be).

Even with no resources or budget, a few hours of work toward answering those planning questions can sometimes provide useful results. Focused energy spent on smart web searches and library inquiries (real librarians are often more powerful tools than web sites) can reveal sources that are infinitely more useful than nothing. Over time, the skills and experience in doing this kind of research will grow, and it can take less time in the future. More importantly, having done some of this kind of work on your own will put you in a more informed position to hire someone to do it for you, should the budget or headcount finally be offered to you.

With any source of data, skepticism and healthy scrutiny help refine and improve its value. Assumptions should be questioned, and known biases of different kinds of research should be called out at the same time the research is presented in a discussion. This doesn’t mean that that data should be thrown out simply because there isn’t enough of it or because there are valid questions about it. Instead, the team should try to look past the flaws to find the valuable parts that can be used to influence discussions and give a better perspective on what the reality of the customer’s experience is like. No form of data is perfect: there are always biases, caveats, margins of error, and hidden details. The project manager has to be able to see past the biases and make intelligent use of what’s available to make better decisions.

Taken From:The Art Of Project Management