Archives for October 2012

That Creepy Thing Called Scope Creep; the Six Steps of Planning and Monitoring to Calm That Creepy Feeling

By M. Duvernet

Oh, the constant fear of the unknown! It is like every main character in any movie – scary or not – when the character ventures to make a choice or open the door to “who knows what?” Nobody can know everything, yet what we do know is important, and applying what we know is what will help get us beyond those unknowns. Just like the movie directors who draw out those storyboards to gain perspectives of the various camera shots, the analyst has to figure out what will be involved in all the project tasks believed to be in scope. Yet, figuring out scope is just the beginning, the rest is all about making it part of the plan and monitoring progress, or is there more to it than that?

Those looming unknowns can only begin to take on shape when the analyst delves into the details, understanding more about the culture of the organization and what sort of documentation has been done in the past. That is why most project work begins with a business case, or a program charter, where the project’s scope is already defined. To further understand scope there is usually some sort of problem statement, or identified opportunity, to supply an overall vision for the work to be done.

Getting a grasp of everything that is a known factor for success is important to any plan. However, one of the most challenging areas of business analysis is figuring out what to plan for in order to set expectations and identify the needed deliverables, so that there is some way to monitor overall team performance toward project success. Just like anyone else blazing a career path, business analysts are expected to become more proficient in their skills as they gain experience.

Planning and monitoring is perhaps the most complex knowledge area in the BABOK® 3.0 (Business Analysis Body of Knowledge). It is Chapter 2 in the BABOK and it covers every business analysis aspect from approach, to understanding stakeholders, to requirements, to processes, to communication, and finally performance. Chapter 2 is 32 pages long, the longest chapter specific to a single knowledge area. While planning is essential to project success, the monitoring piece is associated with overall performance, all of which is a collaborative effort executed by the project team. Sitting at the core of that team is the relationship between the project manager and the business analyst.

Whatever the business climate, or culture, the business analyst needs to approach a project plan by setting some expectations. But this is where things get tricky, as the expectations have to be practical and manageable, as expectations are to be managed thoughtfully to ensure success. However, often times these expectations are besieged by that creepy thing called “scope creep.”

To combat “scope creep” proactive teams often figure out how to identify quick wins and recognize collaborative opportunities where buy-in from all the participants will bring value to their tasks, as well as the deadlines for delivery. The business analyst does not want to be set up to fail, no one does! However, the business analyst and the project manager will often be the ones watching out for scope creep. The very idea of planning is to provide steps for success and define the increments toward that success. It is all a matter of having that important team discussion, to be led by the project manager on behalf of the project sponsor. By defining the expectations the vision takes on more clarity and the definition of success becomes more comprehensive. By creating a collaborative project plan everyone on the team has a stake in the success of the project and everyone becomes accountable to the team to perform to the best of their abilities.

Fundamentally, there are eight questions to answer when creating a project plan.
1.) Who are the stakeholders?
2.) What are the roles held by each stakeholder?
3.) When it comes to the project plan, what estimates are assigned to the various tasks?
4.) What will be communicated to the stakeholders and when, to ensure project progress?
5.) Where do the requirements fit in to the plan and when does the analyst engage the SMEs for prioritization and traceability efforts?
6.) Who will determine what deliverables the analyst is expected to produce?
7.) What process(es) are changing, and who is the expert?
8.) Where can we get the metrics for the current process(es) in order to show improvement?

With all of this in mind, some have even suggested that business analysts need their own methodology, but that is somewhat impractical as there are so many facets to the factors of analysis. The definition of “methodology” is centered round a set process, and there is no one set process to analysis. In fact, there are so many “if this, then this” scenarios depending on the culture of the organization that the processes involved with these facets could be written into infinity. So, to simplify all the aspects around managing scope – to be ready for any unknowns – all we can do is create a plan, then monitor progress of the plan as well as the performance of the project players. The six tasks associated to planning and monitoring, as defined by the BABOK® 2.0 are:

Step 1: Plan approach; define scope, methodology and framework
Step 2: Conduct stakeholder analysis; identify subject matter experts
Step 3: Plan BA activities; tasks and deliverables
Step 4: Plan various communications; communications across various teams, management levels and governance
Step 5: Plan Requirements elicitation and management process; toward achieving sign-off and re-use
Step 6: Manage BA performance; this suggests that the BA maintain quality relationships to ensure project progress and success

This is a monumental task and it cannot be done well without involving the project team, or at least a core sub-set. In some organizations there is a belief that the BA needs to be managed by the project manager. While the project manager is very concerned with time, scope, and budget, their primary concern is the project, this implies that they also manage the team. However, to manage a team, there needs to be a mutual respect among all the stakeholders and agreements regarding estimates and deadlines. If a timeline is unreasonable the PM needs to hear the reality and discover ways in which the team can accomplish the goals and objectives to realize success, even if it is a small success. If the plan is created independently by the project manager, without business analyst buy-in, feelings of uncertainty will surface and any positive team dynamics could evaporate.

Just like in any other project the plan maps out all the “What’s” regarding tasks. The task involving requirements qualify all the “What’s” regarding business, and/or functional, needs; pertaining to definitions, rules, data attributes, system constraints, and quality to ensure valued results. While writing requirements may be rather tedious, it is beneficial to ensure that all the inputs are mapped to outputs and all the outputs are exactly what the business wanted. If some of these aspects are forgotten, or if someone feels they want to control the expectations beyond what is achievable, that is a creepy situation indeed. That is when scope creep can turn ugly. Regardless, the best defense is to make sure that the sponsor and/or executive management is well-informed, instead of uninformed, and as communication is step 4 of the 6 above, there likely will be fewer unknowns to deal with as scope is maintained and project constraints prevail. So while we, as business analysts, may not know everything, what we don’t know, we are eager to learn from others and the willingness to learn is what counts. The bottom line is: To keep that creepy thing called scope creep away, keep focused on the stakeholder goals and communicate, communicate, communicate!