Application of “Design Thinking” Principles to the Complete Definition of Project Business Requirements

“Pay Me Now or Pay Me Later”

Sounds like a hit song or a cry that something may have gone wrong with the relationship at hand.  Turns out that “Pay Me Now or Pay Me Later” describes a number of consequences of project scenarios with which we all are familiar.  It was an expression I coined one time in response to a PMO Manager with whom I worked who wanted to proceed with a contract for services without adequately reviewing the risks in employing that vendor or the services requested.  “Expediency” was the name of the game.  Forget the requirements, just deliver the solution.  Sound familiar?

In this particular scenario, I used a “timeline” to lay out for that Manager the consequences for two scenarios–one in which the vendor did not deliver because the requirements were ill-defined and one in which we took time to evaluate and define the requirements carefully to “frame” the problem adequately.  Of course, this story would not be worth telling if the timeline for the redo and rework ended before the timeline for the complete requirements development.

The Manager signed the contract anyway despite my “drawings.”  And, sure enough, I refrained from saying “I told you so.”

If you survey project teams, project managers and key project stakeholders throughout the various industries that heavily employ project management as a discipline to add value to their respective organizations or to translate strategy into action, you will find that one of the principal problems encountered is the complete definition of project business requirements.  I have alluded to this problem in other blog posts, and in particular in the blog post on “Reframing” the project requirements to provide a more complete and accurate assessment of what problem is being addressed by the project.   Good business requirements are the key to a successful and compelling business case which, in most PMOs, is the basis for approval, rejection or deferral of a project. 

Among the many remedies for the lack of adequate business requirements definition which are found in project literature is the use of very disciplined approaches for defining business requirements by use of templates, coordinated facilitation of group meetings and very detailed descriptions of the “as is” and “to be” project environments.

Every year there is an enormous amount of rework, redo, and replanning of projects due to incomplete and inaccurate definition of business requirements by project teams.   What are some of the shortcomings of business requirement development that most project managers and PMO practitioners will recognize?

1.  Use of a “Once Through” Approach:  The “once and done” syndrome is rampant in business requirement development because of the desire to get on to the “execution” phase which is most often deemed by project teams as the most important phase.  Very little “iterative” approach and retesting of business requirements (and original project ASSUMPTIONS) takes place in actual project work.

2.  Abdication of Business Requirement Development by the Group most affected by the Project:  Usually a business-driven project will have functional and business representatives and stakeholders work with the IT group to develop business requirements.  In many cases, I have seen the business/functional group abdicate its position in the “dialogue” in favor of IT or another lead group taking over the entire process.  This has the effect of the development of business requirements from only one single point of view or perspective and leads to “interpretations ” and “judgments” which, if not tested appropriately, will result in poorly defined business requirements.

3.  Narrowly defined interface requirements between people/functional, functional/technology, and people/technology interfaces:  This results in technical feasibility and market viability often being ignored and the people/functional interface being treated with simplistic ideas for solutions.

4.  Requirements that are not truly “empathic” in their derivation:  Often the stakeholders’ real requirements are not surfaced in the “dialogue” because a singular perspective is applied by the IT group facilitating the dialogue with the business/functional group.  A real visceral understanding of the emotional, social, cognitive, and physical needs of the stakeholder are not defined.   “Empathy” requires looking at things from the users or stakeholders point of view without interpretation on the part of the dialogue facilitator about what the stakeholder or user really “wants.”

5.  Poor “dialogue sessions” between requirements gathering group and the stakeholders or sponsors of the project resulting in rework and redo to create a business case that truly reflects the business requirements being targeted.  I have written about this in another blog post about what to do if your PMO does not execute as expected.

You can certainly extend or expand this list from your own project experiences and I encourage you to write down your observations and test them with others in your project community who are subject to the same project environment.   You will be surprised at the recurring themes, many of which occur because of the similar approaches in building business requirements that are defined within the “structure” of your PMO organization and culture.

You may recognize that one reason for the rise in interest in other methodologies such as AGILE and JAD is specifically because these methodologies address some of the shortcomings in the previous ways in which business requirements were developed.  Utilizing iterative techniques, incorporating more than one point of view and prototyping have been accepted as very applicable to many project situations.

I would like to propose that we take a new approach to project business requirements definition based on principles of “design thinking.”  Design Thinking is an approach to innovation.  In fact, it has often been called “human centered innovation” because of the focus on physical, emotional, social and cognitive needs of the stakeholder or client.  Design thinking has been used successfully by consumer and industrial products companies as well as service providers to open up new markets, define new products, identify new partnerships and to solidify relationship management for parties involved.   Design thinking starts with “empathy” which means looking at things from the viewpoint of the stakeholder, user or sponsor.

Tim Brown, the CEO of IDEO, has written extensively about “Design Thinking” and his reference book on the subject is Change by Design.  And A.G. Lafley and Ram Charan have written about “design thinking” and its associated facilitating framework known as “integrative thinking” in their book Game Changer:  How You Can Drive Revenue and Profit Growth with Innovation.

In a WSJ article early in 2010, Estee Lauder CEO Fabrizio Freda, formerly an executive with Procter & Gamble and a leading advocate of “design thinking” in product development at P&G, said “We don’t want to just do the products that consumers want.  We want to be inspired by consumer desires and surprise them with products that they don’t expect.”  That takes a deep understanding of the cognitive, social, physical and emotional needs of the clients, consumers and customers.  But it also applies to project business requirements development.

Here are some specific actionable things you can do from a “design thinking” perspective to enhance your business requirements definition:

1.  Listen.  Employ “empathic communication” to understand the viewpoints of the stakeholders, users and sponsors.  Listen to the “stories” and “anecdotes” that your stakeholders tell each other.  Often they will reveal their anxieties, worries and fears along with other needs that are never mentioned in their straightforward conversations.  Engage them in “storytelling.”  Recall the account of the SAP project manager from one of my blogs who spoke to everyone who would potentially be affected by the changes introduced by his SAP program.  His method of “empathic communication” elicited many business requirements and business opportunities of a very detailed nature.  It also built “commitment” from the ground up for the program scope, issues and approach which the project manager wanted to pursue.

2.  Look for analogous situations or scenarios to develop deeper insights into the needs of the customers.  Tim Brown, CEO of IDEO, one of the pioneering companies in “design thinking” techniques often talks about some work they did in redesigning the processes for a hospital emergency room.  They talked to so many ER “experts” about what could be done that they decided to seek an analogous situation.  So they studied NASCAR pit crews.  Notice the similarities:  high pressure, high competency requirements, ability to work as a team and as individuals in  a time constrained , close quarters environment.  Often sharing the analogous scenario with your stakeholders can stir their innovative and creative instincts.  I mentioned in a previous post the analogy between project manager and movie director.  Look at the similarities between developing movie script, background, character and actor development and managing a project’s requirements.

3.  Prototype the business requirements situation as best you can.  This will provide additional insights into “real needs.”

4.  Expand your questioning of stakeholders to other than just “superusers” of the systems or new processes.  Tim Brown often tells the story of redesigning cooking utensils for the kitchen.  After continually using experienced cooks for requirements gathering, they brought in a group of children and asked them to put the utensils through their paces in some cooking classes.  The dexterity and handling requirements were immediately accentuated because the children had very few preconceived ideas about how the utensils were to be used.

5.  Read or view some background information on “design thinking” and “integrative thinking.”  Lectures by Time Brown of IDEO can be easily found on the internet.  Also, some business school curricula are now embracing “design thinking” as a basic tool for business strategy and requirements gathering.  See the work of Heather Fraser at DesignWorks which is the model school for design thinking at The Rotman School of Management at The University of Toronto.  Dean Roger Martin’s work on “integrative thinking” can be found in his book The Opposable Mind.

This is just the starting point for opening up a whole new panorama of requirements gathering techniques and validation.  Design Thinkers use the whole world experience in their designs.  Project managers should do the same.

Now, “Pay Me Now or Pay Me Later” should take on a whole new significance to you.  Give me some feedback about your most useful “design thinking” techniques and how you employed them.