Gathering requirements for a project is critically important to the overall project success. Without proper requirements, detailed so they are attainable, a project manager’s ability to achieve project completion or stakeholders’ satisfaction is greatly diminished. Basically, he is shooting in the dark hoping he’ll hit something akin to the thoughts and expectations of the influential powers. For many organizations, requirements gathering is not a process but rather a race to implementation.
A company hired us to help them conduct proper technology selection for a strategic business application. At our first meeting with the client, we asked if requirements had been gathered concerning the new platform. They proudly produced a half-page, bulleted list of items the new system was to provide. We politely asked if that was it. No details. No lists of user needs, business tie-ins, strategic propositions, or customer service thoughts. Ten bullet items of “wants.”
Fortunately, and in anticipation since we had seen this before, we produced a document listing requirements and their descriptions we had accumulated over the years working with other clients. The ‘thud’ on the table startled the client a bit, but he was very excited we had something real from which to work, and more so, because he didn’t have to create the same list and description – the work was done!
What’s the PMBOK® Guide Say?
The Project Management Body of Knowledge (PMBOK® Guide ver. 4) states in Process 5.1 – Collect Requirements, “Collect Requirements is the process of defining and documenting stakeholders’ needs to meet the project objectives. The project’s success is directly influenced by the care taken in capturing and managing project and product requirements.” It goes on to describe the inputs, tools and techniques, and outputs of the process. Fundamentally, the discussion is accurate, but it leaves out the perspective of each stakeholder. While implicitly suggesting the six perspectives outlined in this article, explicitly and proactively viewing each perspective provides clearer and more complete requirements for any project.
What’s the BABOK® Guide Say?
We turned to the Business Analysis Body of Knowledge (BABOK® Guide ver. 1.6) to see if they included discussion of the six perspectives. Again, they discussed the tools and techniques with a mention of various stakeholders. Once again, we want to be more explicitly clear of the viewpoints.
What is IT CubeTM?
The IT Cube is a conceptual method of ensuring all aspects of a project, technology selection, or decision is adequately considered.
Imagine a project as a sphere. Place that sphere inside a six equally-sided box or 3D cube. Each side is transparent so the sphere is easily seen. As you view the sphere through each of the clear sides, you see a different aspect of the ball. From one perspective, the ball may appear blue. From another, peach. From a third, dimpled and so on until you have looked through all six panels. Each view portrays a different “idea” of the sphere.
The same holds true as you focus on project requirements, product definition, service features, etc. By explicitly considering each angle of the project, different requirements emerge. Some may be in direct conflict or compliment requirements from another view. Unless studied in this manner, those requirement clashes may not emerge.
The Six Perspectives
Six perspectives for any project exist. They are:
1. The “Technician”
2. “Technical” Management
3. Business Management and Executives
4. The User or Customer
5. Analysts and Pundits
6. Vendors
Each has a unique view of the project and a vested interest in its outcome, with a possible exception of the Analysts and Pundits, although, their opinions can influence decisions.
Let’s define each and understand their needs.
Panel One: The “Technician”
Our background is IT and therefore we think in terms of business application software and hardware infrastructure. Not all projects are IT focused, consequently, we want to broaden our discussion here to be more generic. The term “technician” has more to do with the people implementing the project. For example, in construction projects, the technician would be the laborer whose skills build. In marketing projects, the marketing person developing plans becomes the technician. The chemist and research scientist would be the technicians in pharmaceutical developments. And so forth.
The questions a technician might ask concerning the project and therefore, their requirements will be more of a technical nature. For example, they might ask
•“How will the new system impact the current infrastructure?”
•“Is this an additional item to our list of services to the organization?”
•“Do I have to learn new information or will my current knowledge be sufficient?”
•“If new knowledge is needed, will I be trained?”
•“Are we doing away with something else?”
As shown, the questions concern the day-to-day operations. Support questions might come to mind once the new “technology” is selected, especially if the technician will be supporting others. In the case of the research scientist, it might be “what support will I get” and so forth.
Therefore, gathering requirements from this group of people is important because they will be the ones implementing the solution and possibly supporting it. As a result, day-to-day operations success after implementation depends on the buy-in and commitment of this group of individuals.
Panel 2: “Technical” Management
“Technical” management concerns are different. This group of people is the managers of the “technicians.” The management must answer to two groups: Business Management and Technicians. Essentially, their requirements include meeting the business ROI, TCO and SLAs while at the same time, supporting the needs of the technicians to operate the technology efficiently.
Their questions may be:
•“How will this technology meet the organizational ROI and TCO requirements?”
•“Will the new system help me meet the SLAs better or more easily?”
•“Will it make the technicians’ work easier so we can provide other services?”
•“Are there other methods of meeting the needs expressed or do we already have systems in place so we don’t need to add another?”
•“Will this meet the business initiatives and align with the strategic plan?”
The questions follow a more business line of thinking, but still with a technical orientation.
Panel 3: Business Management and Executives
Business Management and Executives look at the profit and loss propositions of any new implementation. Their goal is to meet their goals as stated in the strategic plan, along with their own initiatives. Each project should move them further along those plans.
This group’s questions might be:
•“How will this technology align with the strategic plan?”
•“I don’t care about the technology so much. I’m more concerned with it meeting my goals, objectives and initiatives.”
•“How will this project move me further along my initiatives?”
•“How will this implementation make us more revenue or profit?”
•“What is the cost?”
•“What is the priority of the project compared to other needs?”
•“Does the return outweigh the cost or the cultural impact we will incur?”
Notice the questions center around financials and investments of money with overtones of impact on the company environment.
Panel 4: The User or Customer
The users or customers employ the project’s outcome. Their needs determine the usefulness of the project’s result and its use. Whether the project results in a building, a new medicine, a software package to automate tasks, or whatever, the acid test of any successful project is its users’ acceptance. Involving the customer during requirements gathering is essential in the final analysis.
Customers or users may ask:
•“Why do we need something new or better?”
•“How will this benefit me?”
•“Will this help me do my work better, faster, or with less people?”
•“Does it eliminate the frustration I am feeling with the current method or system?”
•“I need this item or this feature. Will the new system do that for me?”
The questions center on their particular set of tasks or duties. They are more tactical in nature, getting down to the day-to-day operations of the business.
Panel 5: Analysts and Pundits
Industry Analysts provide valuable information from a different perspective. They may rate the technology vendor’s stability and longevity – an important aspect for large investments or long term usage. They review the feature set against other offerings of similar ilk and point up the highlights and lowlights of the offering. They present ideas and opinions based on customer surveys and questionnaires. In many cases, they present a more objective viewpoint.
This group of people might wonder:
•“How financially stable is this vendor?”
•“What is their customer support structure? Do they support both large and small customers?”
•“What is the vendor’s current customer base?”
•“How does their product or service feature set stack up to the competition’s?”
•“Do they support just a niche market or do they serve a more general audience?”
•“Do they meet the expressed needs of customers according to our surveys and research?”
•“What advice can I tell my customers about this product or service? What opinions will they find valuable?”
Panel 6: Vendors
Vendors are the ones producing the product or service you want to buy. In many cases, the product or service you are considering will meet some, but not all of your needs or desires. Vendors want to know what your requirements are so they can help you understand which ones they support and how closely. For the ones they don’t support, they will find creative ways to support them.
Vendors will ask:
•“What is your ultimate end result you want to achieve so we can show you how we can help you get there?”
•Why do you think you need that feature or function?”
•“In order for us to be able to support your need, you need to do X, Y and Z. Is that OK?”
•“If this project is successful, what quantity of products or services will you purchase?”
•“How can we aid in making your project successful?”
The vendor is looking to sell products and services. They might place requirements on your project to make it better.
Conclusion
While all the perspective descriptions may not be directly valid for every project, the different angles should be addressed. For example, an internal project that doesn’t use outside vendor offerings still has internal vendors and customers. Those perspectives must be considered and documented. If no requirements come from a particular perspective, then we should explicitly note that fact.
IT Cube is a conceptual model to follow to ensure all stakeholder needs are considered. Missing one side of the cube will leave an opening dumping the project’s success onto the floor.
Tell Us What You Think
We invite you to comment on this article. Does the concept make sense to you? Are there additional sides we should consider? Is it a useful model for eliciting requirements and practical enough to ensure full consideration of stakeholders’ needs? Let us know what you think by leaving a comment.
IT Cube is a trademark of American Eagle Group. All rights reserved. Use of term permitted with credit citation to respective trademark holder.
Copyright © 2009, David A. Zimmer, PMP All Rights Reserved