4.4 KiB
Gathering project requirements using the Open Decision Framework
It's no secret that clear, concise, and measurable requirements lead to more successful projects. A study about large scale projects by McKinsey & Company in conjunction with the University of Oxford revealed that "on average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted." The research also showed that some of the causes for this failure were "fuzzy business objectives, out-of-sync stakeholders, and excessive rework."
Business analysts often find themselves constructing these requirements through ongoing conversations. To do this, they must engage multiple stakeholders and ensure that engaged participants provide clear business objectives. This leads to less rework and more projects with a higher rate of success.
And they can do it in an open and inclusive way.
A framework for success
One tool for increasing project success rate is the Open Decision Framework. The Open Decision Framework is an resource that can help users make more effective decisions in organizations that embrace open principles. The framework stresses three primary principles: being transparent, being inclusive, and being customer-centric.
Transparent. Many times, developers and product designers assume they know how stakeholders use a particular tool or piece of software. But these assumptions are often incorrect and lead to misconceptions about what stakeholders actually need. Practicing transparency when having discussions with developers and business owners is imperative. Development teams need to see not only the "sunny day" scenario but also the challenges that stakeholders face with certain tools or processes. Ask questions such as: "What steps must be done manually?" and "Is this tool performing as you expect?" This provides a shared understanding of the problem and a common baseline for discussion.
Inclusive. It is vitally important for business analysts to look at body language and visual cues when gathering requirements. If someone is sitting with arms crossed or rolling their eyes, then it's a clear indication that they do not feel heard. A BA must encourage open communication by reaching out to those that don't feel heard and giving them the opportunity to be heard. Prior to starting the session, lay down ground rules that make the place safe for all to speak their opinions and to share their thoughts. Listen to the feedback provided and respond politely when feedback is offered. Diverse opinions and collaborative problem solving will bring exciting ideas to the session.
Customer-centric. The first step to being customer-centric is to recognize the customer. Who is benefiting from this change, update, or development? Early in the project, conduct a stakeholder mapping to help determine the key stakeholders, their roles in the project, and the ways they fit into the big picture. Involving the right customers and assuring that their needs are met will lead to more successful requirements being identified, more realistic (real-life) tests being conducted, and, ultimately, a successful delivery.
When your requirement sessions are transparent, inclusive, and customer-centric, you'll gather better requirements. And when you use the Open Decision Framework for running those sessions, participants feel more involved and empowered, and they deliver more accurate and complete requirements. In other words:
Transparent + Inclusive + Customer-Centric = Better Requirements = Successful Projects
via: https://opensource.com/open-organization/18/2/constructing-project-requirements
作者：Tracy Buckner 译者：译者ID 校对：校对者ID