Refine Scope
I think we have all been there—you know, assigned to a project where no one was really sure what was being built or how big it was. These projects tend to grow overtime and are often delayed as a result. This is an issue in understanding the project scope.
The business analyst will help you identify and articulate the solution scope needed for a successful project. Too often, in a hurry for answers, project assumptions exclude needed items and include items that will not bring value to the business. Is providing training to end users required for the solution to meet the sponsor’s expectations? Will an interface be required for the solution to speak to another solution? Are there industry requirements that dictate solution features? The product scope is different from the project scope. In product scope we only care about what the solution looks like, what we put into the hands of the customer. In project scope we include deliverables that are required for the project but are not a tangible piece of the product such as project management or transition to operations. In Figure 10, the work breakdown structure (WBS) designates the product scope within the project scope.
Figure 10 Example of Work Breakdown Structure
The business analyst has tools available to them to determine the product scope. Figure 11 is an example of the use case diagram. Use case diagrams approach scope based on who and what will be interacting with the system, versus not. In the following example we can see how the business analyst is questioning whether the scope should include the ability of a project stakeholder to run a report. This is just one example of the type of assumption or requirement that could easily be missed without thorough analysis of the scope. Let’s see how scope is handled in our case study.
Liz’s business case for the Requirements Management Tool (RMT) project was selected for investment by Weaver Systems with Matthew Simmons, the Director of Systems Development, joining on as the project sponsor. Mary Kennedy was assigned as project manager, and Liz remained as lead business analyst on the project.
The first order of business for Liz was to help shape the scope of the project. She worked with Matthew and Mary to get an idea of the vision for the solution and start documenting what would be possible given the schedule and budget provided for the project. She talked to some key stakeholder to find out what they envisioned for the solution and to start capturing some high-level requirements. One idea came from Tom, the Development Manager, he wanted the ability to run his own reports on requirements from the system. Liz could see where this may help in alleviating the business problem with a new means to communicate requirements, but she wasn’t entirely sure it should be included in the solution scope given the time and budget constraints. Liz prepared the use case diagram shown here to present to Matthew and Mary to help in the discussion about what should and should not be in scope for the project.
Figure 11 Example of Use Case Diagram
Mary was concerned that the scope was more than could be accomplished given the project constraints. Matthew asked for more information on how it would impact the project to include a report user interface for other project stakeholders. Liz pointed out that this would likely mean several things:
• Developing additional canned (static) reports that would be meaningful to project stakeholders
• Additional training needs for those users
• Potentially a separate user interface for the report users to run reports
• Additional online help to support the report users
Liz further offered her opinion that this might make sense as a future enhancement after the system is implemented and the organization could better gauge how reports would be received and used by project stakeholders.
Matthew agreed that it would make more sense to see how the system and reports were used before building functionality for users outside of the business analysis team.
Determine Project Approach
The next task for the project manager and business analyst is to decide on the approach that16 will be used for the project. Agile was described in detail in the Introduction of this book. You may have gotten the impression that I do not believe Agile has a role in projects. I do believe that some projects are better suited to Agile or LEAN methods rather than the traditional waterfall approach. The BABOK® Guide provides some guidance on choosing an approach that the business analyst can confer with the project manager on to help determine the approach that will provide the greater advantage to the project at hand. The business analyst and project manager together can determine the best approach for the project at hand.
Generally, projects that have negotiable scope may be better suited to Agile methods, where the team is focused on one small high-priority piece of the project at a time. This allows the critical components of the solution to be developed and deployed early although some features may be missing. The “Plan” evolves over time through the product backlog and the team’s velocity to complete work. Here, the business analyst will be scoping the project through the product backlog and refining requirements within each time-boxed sprint.
IIBA refers to this as “change-driven”, whereas PMI refers to it as “adaptive”.
Waterfall
Waterfall is a project approach where each phase of the project is fully completed before moving on to the next. This was first described in 1970 by Dr. Winston W. Royce in Managing the Development of Large Software Systems. What this means for business analysis is that all requirements are elicited, analyzed, communicated, and approved before any development begins. Design and coding will happen later in the project, but will be based on completed requirements that will not be at risk for major changes. While Dr. Royce advocates for frequent review and feedback loops within his paper, the application of waterfall in practice generally does not allow for this.
Traditional Waterfall
In projects where the deliverable is not negotiable, extensive planning and evaluation is required to determine the project’s needs: time, budget, staff skill, and needed resources. A full understanding of the project scope and specific requirements are needed to develop a realistic plan. The business analyst will be communicating scope and requirements to the development team at the level they need to accurately plan and estimate prior to any work being done in the solution itself.
IIBA refers to this as “plan-driven”, whereas PMI refers to it as “predictive”.
A business analyst who is participating in the project approach selection should have a thorough understanding of and experience with each. A business analyst working on the project activities in either approach needs to have a thorough understanding of and experience in these types of projects. All of the solution downstream work is dependent on the business analyst’s deliverables. They need to be included in the approach discussions in order to help inform which approach will work given their education and experience. A brief history of waterfall is provided earlier. Do you know what approach Liz and Mary will take in the case study? Let’s take a look.
Liz and Mary spent some time discussing the RMT project to determine the best approach for the project. They noted the following:
• This was an off-the-shelf system purchase, not a development project
• System configuration and user education are needed for successful implementation
• Requirements would be needed to configure, implement, and train users on the new system
• The initial users of the solution are internal, business analysis, staff only
Moving to a RMT for requirements would be a big change for the organization. Liz and Mary agreed that the initial release should be as polished as possible for favorable first impressions of what the system could do to facilitate greater acceptance by business analysts and other project stakeholders alike.
They decided that the waterfall approach made sense for two reasons. First, it would allow Liz to get requirements for the solution upfront so that the system could be configured and the user education components could be fully in place upon implementation. Being able to tell folks exactly what they will get in advance is one way to manage organizational change. Secondly, much of the work needed to implement the solution within the organization would be more back end and infrastructure items that couldn’t be implemented piecemeal. Since Agile looks for “potentially releasable products” early, this would not be feasible. Liz and Mary decided that the initial release should use the waterfall approach, future enhancement projects may be better suited to an Agile approach if funded down the road.
Your Assessment
For the selected project …
1. What was the scope of the project as you understood it?
2. Is this project on track for delivering the selected scope? If not, are there more or fewer features than originally anticipated?
3. What approach was used in delivering the project?
4. Did the project team utilize the approach selected in the best way?
16Royce, W. (1970). Managing the development of large software systems. Proceedings of IEEE WESCON 26 (August): 1–9. Available online at http://agileconsortium.pbworks.com/w/file/fetch/52184636/waterfall.pdf.