CorrectProject teams and their members move rapidly from one project to the next and are often under tremendous pressure to produce deliverables and results. Arriving quickly, then disappearing as they move on to the next urgent organizational need, project teams are becoming business and technology agnostics. Yet specific business knowledge is essential for project success and the critical role of providing the relevant business knowledge to the project team belongs to you, the functional manager. This business knowledge becomes the foundation for project requirements, a key component to your project scope. A relatively stable, well-understood project scope shortens project life cycles, while scope creep increases project durations and costs.
Poor requirements are a common cause of project failure and are often rooted in a lack of understanding of the business. Although project managers pride themselves on being generalists, they often fail to acquire and utilize the business matter expertise that is available to help them on projects. As a result, changing requirements and scope creep can lead projects to the grave.
A failed project can have a serious effect on a functional manager’s career. Whatever a project’s outcome, you may be indelibly associated with that project because the benefits to the organization are so important and the impact of failure is so great. As a functional manager, you play a key role in ensuring that business matter expertise is used on your project, because you are the one who is most likely to have an in-depth understanding of how the company works. A functional manager must have an appreciation for the importance of business knowledge to the success of a project, and he or she must ensure that the project team has access to information that provides the proper understanding of the business.
Your organization’s attempt to create strategic change requires a provider/customer relationship based on mutual respect and common understanding. Your project manager, if you are fortunate, is an expert in project management, but probably not an expert in your business. However, to establish trust in the relationship, the project manager must demonstrate a genuine interest in and solid understanding of your needs. A seasoned project manager understands this customer perspective and learns how to recognize quickly the key components of the customer’s business and need. The success of this provider/customer relationship depends on the provider’s objectivity and ability to manage projects and become familiar with your needs.
Your project manager must develop meaningful, trust-based relationships with strategic stakeholders, including sponsors, influential parties, and team members. This trust begins with credibility that encompasses his or her project management expertise and its applicability to the present situation. As the customer, your trust is crucial; ultimately, you are delegating to your project manager a level of authority to act on your behalf. A lack of trust is a barrier to this delegation. You will not delegate leadership, only managerial tasks, to a provider who does not thoroughly understand your situation.
A good functional manager will communicate the vision of the initiative, particularly during its launch and early planning stages. Although you are likely very busy and distracted by daily responsibilities, the project vision must be communicated continually throughout the project. In many projects, that communication is seriously neglected. You have to transfer a significant base of knowledge about your business processes, procedures, policies, and exceptions, and how they are changing. This will allow your project manager to continually convey the vision of the initiative to influential stakeholders, particularly those more distant or possessing a distorted view of the initiative. These less-involved stakeholders can create chaos by their complacency, lack of support, or even active resistance. The projection of the vision can only be done effectively if you and the project manager share a common understanding of where you are today and where you are heading with the project. Through this deep knowledge of the business process, your project manager becomes fully entwined in the endeavor, making it difficult to escape leadership duties. And that is exactly what you want.
As a functional manager, you can—and must—play a vital role in sharing the knowledge of your business with the project team. Begin by assuming that the project manager and team know less than they pretend to know and start this conveyance of knowledge with simple steps. One common approach is conducting a walkthrough of various processes. Although walkthroughs are certainly helpful for observing the work, they can turn out to be counterproductive if they go too deep, too fast. For example, walkthroughs may highlight specific situations that are not part of the core business process. Or they may include discussion, at lightning speed, of myriad undocumented exceptions and business rules. A better approach is to start at the organization level and identify the significant business units and how they interact. Before presenting the details and nuances of a process, make sure your project manager and team understand the bigger picture of the process. The effort to grasp all the details of your business quickly is likely to intimidate your project manager, thus shortchanging the process. The project team focuses on the details in front of them without appreciating the relationships and impacts to other organizational processes. Drive home the big picture first and make sure your provider understands it before focusing on the more granular detail.
I experienced a great example of this one cold week in Ohio, where I found myself taking on a large business process automation project for a mortgage company. I was fortunate to have a functional manager assigned to shepherd me through the organization. Before the global financial crisis, the company’s processing, underwriting, closing, and selling of mortgages was complex. Their business had hundreds of exceptions; in fact, entire teams were staffed solely to deal with exceptions. But before getting into detail, John, my partner in this provider/customer relationship, walked me through all of the different aspects of the organization. Many of these departments were located in different buildings in the same city. We spent two days jumping in and out of his car, driving to different offices, and meeting and greeting the key stakeholders of this project. Some were more involved than others.
John’s goal was to help me understand the organization and how it operated; he also wanted me to connect names and faces with the key business processes. This provided me with the opportunity to construct a high-level, visual diagram of the basic inputs and outputs of the organization’s core business processes. Many project managers do not want to take the time to construct this big picture diagram, or they simply assume that they understand it instead of validating their assumptions. Worst of all, they may be stuck in the mindset that a project is only about technology, completely ignoring the business aspect of the project. Let’s face it, some project managers are enthralled with technology and love to tinker with the newest gadget, release, or promise to simplify, modernize, or revolutionize their world.
John allowed me to create this mental construct of the organization that preceded any formal documentation of business processes. It greatly facilitated our efforts to define scope definition and gather requirements, which began the next week. Your provider will not have the time to document your organization’s business processes in their entirety, but these processes are usually documented already or can be constructed at a high level that shows linkages between major processes and identifies inputs and outputs across business units.
Using business process knowledge is critical so that your provider can understand the inner workings of your organization. However, one challenge is that the people involved in these processes often don’t speak in business process terms but rather in task-specific terms, which does not provide the project manager with the needed information. The employees are typically so close to the day-to-day work that they cannot see the bigger picture. Observe your project manager: if astute, he or she will ask questions using terms that people can understand, quickly translate responses into process terms, form a mental picture, and then validate any assumptions or clarify outstanding questions. As a functional manager, your job is to facilitate the process of identifying the major process activities of each organization and the relationships between them. Ensure that your provider can document major inputs and outputs to each process and identify the supplier and customers (internal and external) of the processes. Allow the provider to discover why certain activities are performed, and assist in identifying the key metrics (actual and desired) of major processes and activities.
Laying this groundwork early on in the project will allow the writing of good requirements against validated business processes. If your provider lacks a solid understanding of your organization’s business processes, that will impact the validity of your requirements during implementation.
One of the most common words heard in project meetings is requirements. “The requirements are not complete.” “We need to sign off on requirements.” “The requirements have changed.” “The requirements are outdated.” “Who is updating the requirements?” And my personal favorite, “The requirements are locked down.”
Requirements are the basis for the project plan. If requirements are flawed, the project plan is flawed. Writing requirements is a unique skill, particularly on software projects or for projects in which customer and users have difficulty assimilating the final product from written words. When requirements are written well they are all of the following:
Correct
Unambiguous
Complete
Verifiable
Consistent
Understandable by the customer
Traceable
Design independent
Concise
Organized
What exactly is a requirement? It’s vital that you, the functional manager, have an in-depth understanding of what we mean by “requirement,” because the project team will rely on you to communicate requirements for documentation as a part of the project scope.
A requirement is a condition or capability needed by a user to solve a problem or achieve an objective.1 Often, a system must meet or possess this condition or capability to satisfy a contract, standard, specification, or other formally imposed document. Thus, the provider will be relying on you to provide clear, articulate information. The most common mistake is not considering requirements in light of a business process or processes. Understanding business process impacts is critical, not only to the specific process on which you may be focusing, but also to related processes.
Your project manager, let’s hope, is skilled at asking the right questions and capturing your responses appropriately. Sooner or later, a requirements document will show up in your e-mail inbox and you must review it and determine whether these requirements are accurate. By then, your project may be slightly behind and your provider needs a review quickly so the design and build phases can begin. Sound familiar? What should you look for? How do you know if these requirements are written properly?
Requirement documents come under many different names depending on the organization’s methodology, the project environment, and the nature of the work. You can expect a Project Definition Document, Product Requirements Document, Project Data Sheet, Business Requirements Document, System Specifications, Functional Requirements Document, or Technical Software Specifications, to name a few.
Your document also may include different types of requirements: business or functional requirements that describe how functions of the system work for business stakeholders and users such as yourself, and more technically written requirements that are addressed to engineers and technical project team members. Business or functional requirements are always written first and you must be able to sign off on these requirements with confidence.
Requirements should be specific, measurable, attainable, realistic, and traceable and timely. This is commonly known as the SMART model for requirements. This acronym is useful only if you can apply it to the document your provider is asking you to review.
Specific. A good requirement is specific, not generic. It should not be open to misinterpretation when read by you or others. This attribute is the most important to get correct. Be wary of conjunctions (and, or, but) because they can confuse or misconstrue the meaning. Avoid indeterminate measures (fast, immediate) because they are open to wide misinterpretation, which results in dissatisfied customers and conflict.
Here is an example of a requirement that is not specific: The report should display all the quarterly data from the accounting department. Anytime you see “all,” “always,” “never,” or other global adjectives, reject the requirement as too ambiguous. What if the accounting department adds more data? Do you need to immediately update the report? A better requirement would be: The report shall contain the following columns: Total Sales for the Quarter, Retail Price, Discounted Amount, Total Units Sold, Total Cost of Goods Sold, and Margin.
Your requirement should list every column, no matter how many there are. A subsequent requirement should also list the column headers; another requirement should list any subtotals or totals needed by the user. The requirement still has a level of ambiguity, however. Consider the specific calculations and definitions of columns such as Margins. Should that include commissions to salespeople?
Measurable. Measurable determines whether you can verify that the requirement has been satisfied. Requirements must be verifiable. Non-quantitative terms such as “best,” “optimal,” or “fastest” cannot be verified during your acceptance.
Here is a classic non-measurable requirement: The system shall have an optimal response time for the end-user. There is no way you can be successful with this requirement once the new system goes into production because “optimal” is not defined and really cannot be defined. A better requirement would be: The system shall have user response times on user interface–driven clicks that are 2 seconds or less during the hours of 7AM–7PM, Eastern Standard Time, Monday–Saturday. The subsequent related requirements may further clarify user interface-driven clicks, such as whether they include reports or database queries. Another obvious question for this requirement is how will these be measured, with a user holding a stopwatch? Or does this create additional requirements for this data, such as a system response to capture and report user interface-driven clicks?
Attainable. Attainable is also referred to as “achievable,” “actionable,” or even “appropriate.” All are fine attributes and are intended to ensure that the requirement is physically able to be achieved given existing circumstances. There is arguably overlap between attainable and realistic, our next criterion.
Is the following an attainable requirement? The quarterly marketing sales report and the quarterly financial statements shall both be delivered on the 1st business day of the month. Maybe … or maybe not. Running the financial statements may take 28 hours, or perhaps they have to be approved by the comptroller before they are released. Delivering both reports on the same day may be impossible with the current systems available.
This may be more attainable: The quarterly marketing sales report will be delivered on the 1st business day of the month; the quarterly financial statements will be delivered on the 5th business day of the month. Notice how the requirements have now been broken out into two discrete requirements.
Realistic. As the customer, you must make sure that your requirements pass the realistic test. Many customers want to believe that their requirements are realistic, but often they are not. When evaluating whether the requirement is realistic, consider other constraints of the project and organization. Is the following realistic in your organization? Phase I of the system sales reporting module will be delivered into production on or before March 15, 2012. At first glance, this is a good requirement. The specificity of the date is helpful, but if you are not working in a close provider/customer relationship, the provider may believe the amount of work required and the resources available to work on it make the date unrealistic. However, if you have participated in building a meaningful project plan with your provider, you will be less likely to impose unrealistic dates on the project team. Unrealistically imposed dates will ultimately come back to haunt you when output lacks quality, has missed requirements, and may not meet your business need at all.
Time-Bound and Traceable. Time-bound means that your requirement should specify when or how quickly a requirement needs to be completed or executed to satisfy your business need. Not every requirement statement must have a specific date; however, your project may need some functionality before other functionality can come into play. Thus, organizing or identifying specific requirements that have different time constraints or delivery expectations is necessary. Requirements also should be traceable through design, coding, and testing documentation. By now you will recognize that the following requirement is weak: The report will be available soon after month-end close. A stronger requirement is: The report will be available by noon on the first business day after the successful completion of the month-end accounting reports. This explains to the customer when they can expect the report (first business day, not on a weekend) and only after a successful run of the closing monthly reports from accounting.2
Requirements are typically enumerated in discrete statements. These discrete statements can stand alone or have relationships with other statements, as illustrated here:
1.1 The system will require users to manually change their passwords every 30 days.
1.1.1 The system will require passwords to be unique from previous user passwords used in the past 6 months.
1.1.2 The system will require passwords to consist of a minimum of 6 characters, including a combination of alpha, numeric, and special characters.
Requirement 1.1 is the “parent” requirement and 1.1.1 and 1.1.2 are the “child” requirements. These requirements are related just as children are related to parents.
A bit more information may help you on the actual phrasing of requirements. When written well, requirements:
1. Define an object, state, or function.
2. Limit or control the actions of an object, state, or function.
3. Define relationships between objects, functions, and states.
A good requirement will specify an object; for example: The system will require users to manually change their passwords every 30 days. In this requirement, the object is the password. The requirement is placing a control on the actions of the object, requiring it to be manually changed every 30 days. The next requirement is: The system will require passwords to be unique from previous user passwords used in the past 6 months. The object is now being related to a state, unique, with a defined time frame, 6 months. The last requirement in this series is: The system will require passwords to consist of a minimum of 6 characters, including a combination of alpha, numeric, and special characters. The object’s attribute characters are being defined as a minimum of 6 alpha, numeric, and special characters.
Books and classes abound on how to write good requirements. It is truly an art form and some project workers make it their career, particularly in multimillion-dollar contracts that impact the health and lives of ordinary citizens. Requirements and their interpretation and meaning can mean the difference between acceptance and rework, project success and failure, and even life and death.
The challenges with defining requirements are real; first, the English language is naturally ambiguous, and for something new—a product, service, or result—users will have differing expectations. The learning effect also presents a challenge: as users assimilate the project output, they learn more about what they do and do not want in that product, making the requirements dynamic. Finally, business conditions can change over the course of the project, driving changes to requirements.
As a critical part of this provider/customer relationship, you play an integral role in ensuring that the project team captures good requirements. Work with your provider to create flexible plans with iterations, and collect user feedback often. You must insist that your project team shows you results early and often to spur the necessary learning and assimilation process for you and your customer team. Project teams take a serious risk when they wait until project components are near completion before showing you. To support this overall process, you, as a customer, must create an environment in which unfinished work can be reviewed objectively.
In 1995, Pixar Animation Studios released their first blockbuster, Toy Story. As the first ever full-length computer-animated film, it represented a breakthrough for the industry and signaled a bright future for the company. In the 13 years since then, Pixar has enjoyed 10 more huge successes, including Toy Story 3 in 2010.
Pixar’s creative genius has remained strong over a remarkable period of time. How have they managed to keep their films from becoming tired or predictable? The answer lies in the studio’s self-described peer-driven approach to the generation and development of creative ideas. Pixar’s president, Ed Catmull, described the process as one that makes it “safe for people to share unfinished work with peers, who provide candid feedback.”3 In contrast with typical management techniques that try to reduce risk as far as possible and provide for communication along “proper channels,” in this article Catmull presents five daring steps to creative success from within:
1. Empower people to generate ideas. Instead of seeing creativity as a “mysterious solo act,” it is far more advantageous to see it as the result of free correspondence and collaboration across artificial boundaries. Why limit ideas to one department?
2. Create a culture of peers in which raw, unfinished work is acceptable. This keeps potential for improvement at a maximum and ideas fresh and ready for collaboration.
3. Keep communication unrestricted. If things don’t have to wait until the meeting, or until the manager has been told, hallways and chance encounters can become a birthplace for ideas and an asset to the entire project.
4. Encourage learning, and grow your people in multiple skills. This helps everyone understand and appreciate what various departments and divisions are doing. Additionally, people can see how their work fits into the project as a whole, giving their work more value.
5. Use post-mortems to discuss both the positive and the negative aspects of the project. By not focusing solely on what went wrong, you end up with a more honest discussion about the project as a whole.
Obviously, these methods have worked for Pixar, but can they work for other companies, and for projects whose outputs are not artistic in nature? Is creativity really that big of an issue for the majority of us who aren’t making movies? Yes, creativity is important. The reality is that projects are in and of themselves creative processes, no matter the form of the end deliverable. Project Management Institute (PMI) even defines them as such: temporary undertakings that create something new or do something that’s never been done before. Even if project managers are not engaging in something “creative” in the artistic sense, they are definitely bringing people together, united by a common vision, in pursuit of an end that does not yet exist and will not exist unless they create it.
With their providers, customers must set the tone for collaboration and communication on their projects and they have much responsibility for the creativity of their teams. If the failure of an idea is linked to an individual, team members are unlikely to think boldly and unconventionally. Likewise, if work areas are strictly divided, individuals are less likely to consider how their work affects the project as a whole and the overall focus remains narrow and linear.
The problem that remains is that of risk management: how are we to keep risk under control while encouraging as much creativity as possible? Catmull’s perspective is striking: he goes on to say, “Management’s job is not to prevent risk but to build the capability to recover when failures occur.”4 That is to say, risk management shouldn’t be about preventing leaps of faith, but about taking care of their consequences. Ask yourself right now: what am I doing to encourage leaps of faith by my team, while planning for the potential consequences?
For provider/customer partnerships, the ability to foster creativity is a critical skill, and not the easiest one to acquire. No project is completed because of a single idea, but because of the intersection of a multitude of ideas; the more ideas you can bring together, the greater your chances of success.
Work closely with your project manager to prioritize requirements and forecast new requirements. Sort out competing requirements among multiple customers and help the project manager manage differences. The reality is that the relative cost to repair a poor requirement becomes significantly greater the further you get into the project.5
Educated customers know what they want. That includes knowing how to articulate your wants to your provider by stating requirements clearly and unambiguously, signing off on them, being realistic about changes to requirements, proactively forecasting new requirements, and updating your provider regularly.
Insist that your provider include pictures, graphs, and flowcharts to make the requirements more understandable to users; demand that they show you drafts early and often; and have a change control system in place to monitor requirement changes. The bottom line is, if a requirement can be misinterpreted, it will be. Good requirements are the output of a solid provider/customer relationship that is based on a common understanding of the current state and the envisioned future state.
One phase that almost everyone in basic project management training classes seems to understand is scope creep. Next to requirements, it seems to be the most-used layman’s term in the daily events of project life. Scope creep is directly related to requirements and their mismanagement. A typical scenario plays out on projects: requirements are rushed to completion, the documents are not properly scrutinized by the customer, and project teams do not facilitate the consumption of them. E-mails go out with deadlines to review requirements; customers review them in haste, perhaps while on a conference call, just to get something off the to-do list. Design and build activities move forward and the delivery of the project has gaps in functionality, some documented, some not documented. Eager-to-please project workers try to squeeze in additional functionality in response to demanding customer expectations. The precedent is now set for continuing growth of requirements, many of which are informal, undocumented, and have not been through an impact analysis. This cycle continues until project schedules and budgets are in a shambles, then management steps in to start the post mortem.
Scope creep has many root causes besides poor requirements, such as undisciplined customers, use of the wrong system development methodology, and not having clear linkage of requirements to the business process. Further impact can come from changes in the business environment, new regulations, market demands, competition, and cost factors.
Functional requirements should always support the business process. Business may be changing as a result of process improvements, regulatory amendments, and technology advances, and requirements must anticipate these changes. An effective practice for project managers is to develop high-level, one- or two-page process flow maps of the business area’s current state process affected by the project and the desired future state process. This should be understandable but not overly simple or obvious; if it suggests to you that the project manager doesn’t understand your business, then he or she probably doesn’t. It will be your job to rectify any deficits in the provider’s understanding! The flow maps should reflect all the major business areas impacted by the project, thus serving as a verification of the scope narrative. These current and future state process maps can be included as a part of scope narrative to increase the assimilation of the desired change being brought about and its impact.
I prefer simple diagrams that focus on high-level business processes and their interaction between groups of users or departments. These current and future state documents can be enormously helpful in keeping all the players on the same page, creating a common understanding of the project scope as it relates to the affected business processes, and setting the stage for more detailed functional requirements. Process maps with greater detail can be made if needed. To generate good requirements, project managers must understand the individual process steps, what users need, when they need it, and why. With process maps, defining process requirements takes on a new meaning. It’s no longer a jumble of features or functionality, but shows specific functionalities that can be linked to specific business processes. At this level, design of the solution or selection of a vendor or product becomes much easier.
In making the maps, the project team evaluates each business process step for its project requirement applicability. In other words, is the solution being considered being used in this process step? If so, what should the solution do to facilitate the process? The more detailed the functional requirements, the better the likelihood of satisfying stakeholders. To eliminate duplication of requirements, a simple spreadsheet can enumerate the requirements and trace them to the business process.
Part Two of this book covers specifics of business process mapping and how to create various types of maps. For now, remember that the key to stabilizing requirements is through a partnership developed in the provider/customer relationship. The functional manager plays a vital role in transferring business knowledge to the project team and participating in the process design and the requirements that support the process design.
1. Alan M. Davis, “Software Requirements—Objects, Functions and States,” in 201 Principles of Software Development (New York: McGraw-Hill, 1995), 15.
2. Jessica Johnson Popp, “SMART Requirements,” http://jessica80304.wordpress.com/2008/08/04/smart-requirements/ (accessed March 14, 2011).
3. Ed Catmull, “How Pixar Fosters Collective Creativity,” Harvard Business Review, September 2008, 68–72; http://computinganddesignthinking.pbworks.com/f/W4-Catmull-CollectiveCreativity.pdf (accessed 11/1/11).
4. Catmull, “How Pixar Fosters Collective Creativity,” 66.
5. Davis, “Software Requirements—Objects, Functions and States,” 25.