23 May 2011
Requirements = Scope: Interlude
If Perceived Experience beast Expectations, then you are well on your way to success.
In the context of this discussion; Scope = Requirements, what does this mean?
A few posts back Shim asked me if I am really am saying a Business Analyst should be training project progress. The answer is yes, in some cases. If you are defining the project's outputs through a set of requirements statements, and you are invested in tracking their progress through the delivery cycle, then you are already doing this.
Let's just put it on the table for the project community that the BA is fully equipped and ready to take over. Move aside project manager :)
Okay - some projects in some contexts.
The goal of this discussion is to challenge the status quo, and to share some techniques about how to improve project outcomes.
Yesterday my post was about expectations and perceptions. Let's link this to the theme of Requirements = Scope.
As a Business Analyst, you have defined a set of requirements. You have put a proposal to the stakeholder community and are now managing their expectations about what is coming through the pipeline.
How do you use the information available to you to delivery effective messages? How do you ensure effective management of expectations and the flow on of project success?