Playing the Critical Friend through Enterprise Analysis
Successful projects start with a good and clear understanding of the organization’s goals and objectives and a clear understanding of the project’s requirements.
One significant challenge with projects can be the gap between what the stakeholders ask for, what they need, and what they can afford. There can be a further gap between what the stakeholder expects and what is actually delivered. Good quality business analysis helps to plug this gap.
Although the discipline of business analysis is young, it isn’t new. Requirements engineering is older still—history is littered with examples of expensive IT project failures and projects where the users haven’t received what they expected. How can this be? And how can these types of project failure be avoided?
One sub-set of business analysis that contributes toward project success is enterprise analysis. Enterprise analysis focuses on achieving a solid understanding of the organizational problem or opportunity and the business and customer value that the organization is hoping to achieve.
Enterprise analysis is sometimes seen as a “one off” activity that takes place early during the project lifecycle before formal requirements elicitation commences. As Kevin Brennan explains in his blog, while it is inevitably true that it should take place early to answer the “big questions,” it should also take place during the project for the smaller questions. When requirements are being prioritized, it’s an opportunity to refer back and ask “How do these requirements solve our problem?”
Sometimes the act of eliciting requirements might help you refine your understanding of the problem itself. With this understanding the risk of a gap between what the stakeholders need, want, and expect is reduced.
Stakeholders won’t always want to hear these questions. When a shiny new requirement is being debated, they might not be able to see beyond the shimmering silver packaging. An important part of enterprise analysis (and business analysis for that matter) is acting as a critical friend.
I’m sure outside of work we all have close friends that we trust, the people who will provide us with open and honest feedback. Yes, sometimes we really do need someone to tell us that “Red isn’t your color.” or “That shirt that you loved twenty years ago really doesn’t suit you now that you’re in your 40s.” The same is true within projects.
Being objective change professionals provides us with the opportunity—and the obligation—to sometimes ask difficult questions. To be a critical friend to the business, ask questions like:
Can you tell me how that requirement relates to the project goals? Have the goals changed? Do we need to revisit the scope and business case?
Is that really a "must have" requirement? What business value does it deliver? Are you telling me that if we deliver a system with all requirements except that one, the system won’t be valuable?
Clearly the way that we ask questions like this will vary depending on the stakeholder. Questions must be asked with respect and rapport—but it’s important that they are asked one way or another. It is the difficult questions that keep projects on track.
