By George Pitagorsky | Follow on Twitter!
Agility implies an adaptive, controlled, fluid process based on flexibility and dynamic, engaged collaboration among stakeholders. Agile projects, when we'll managed, are controlled yet open to change as requirements evolve through the interaction between developers and their clients and managers.
Adaptive, flexible and dynamic process creates a dilemma for those who want certainty based on unchanging plans. As I explain in my forthcoming book, Managing Expectations: A Mindful Approach to Achieving Success, setting and maintaining realistic expectations among stakeholders is a critical success factor. Projects are successful when stakeholder expectations are met. Expecting certainty is sure to lead to disappointment.
Managing expectations means establishing realistic expectations – scope, time and cost, the likelihood of change, working conditions and relationships – at the onset during the initiation and planning processes and adjusting them as reality is experienced during execution. Planning is not over until the project ends.
Incremental, iterative planning with continuous monitoring and control is the process of reassessing the plan as things change, adjusting for those changes and letting all interested parties know what to expect going forward regarding schedule and cost. There are many causes of schedule and cost changes that occur during projects, for example loss of resources, incorrect duration, learning curve and effort estimates, executive management and scope changes. In this article the focus is on scope changes and the way they are handled in agile projects.
Scope Management in Traditional Projects
Scope defines what the project is to deliver. Since there is a likelihood of changes in requirements and scope in agile projects as stakeholders receive and evaluate results as they are delivered, refined and accepted, it is necessary to iteratively refine plans and adjust expectations.
In traditional projects scope is defined in a requirements specification document in terms of functional and non-functional requirements. Functional requirements state desired system behavior. Non-functional requirements address all the over aspects of the project. They include quality expectations, performance constraints and compliance with standards.
Traditional requirements documents are comprehensive and deep. Business analysts work with clients, users and user ombudsmen to describe what they want the system to do and how it will appear. Requirements are defined before any product is delivered. Traditional requirements documents describe the full range of requirements in significant detail. This makes their preparation costly in time and effort. Since detailed requirements are often created without experiencing the expected deliverable, it is likely that requirements will change when the deliverables are received, often during user testing.
The requirements are the scope baseline for the project with product developers working to fulfill them and manage changes. Scope changes are controlled to identify, assess, authorize each change and make sure that it does not jeopardize meeting project time and cost constraints or that those constraints are changed accordingly to manage expectations. Generally the process for managing scope or requirements change is bureaucratic, requiring documentation and levels of approval based on the size and impact of proposed changes.
Many feel that the objective of change control is to inhibit changes. While this may be a consequence, particularly when time and cost constraints are rigid, the rational and useful purpose of change control is to ensure that changes are made when warranted and that expectations are managed so that the impact of changes on cost, quality and schedule are known. Although we cannot stop change, we can moderate its flow, frequency and impact.
Agile Scope Management
There is a need for written scope definition and formal change control in agile projects. In agile projects, instead of highly detailed requirements, requirements are at a high level. Scope is defined to identify the overall functionality to be delivered in the form of user stories and non-functional requirements. For example, an application development project would identify the full range of product functions, standards regarding the look and feel of the user interface, volumes and frequency of use, response time and other performance requirements. A user story is a brief description of a desired function for a role or actor.
These requirements would not go into each function’s detail. As the project progresses there are waves of mini-development time boxed events or sprints planned in to deliver selected user stories. Each sprint addresses one or more user stories selected to fit the sprint’s time box. During the sprint the development team with members from the using environment (the customer), work to define the detailed requirements and iteratively deliver product. The delivered product validates that requirements have been understood and gives the customer the opportunity to see if the requirements meet the intended needs. The requirements and product are refined in real time without the need for a high-level change control process. Although it is a best practice to document the changes so that there is an audit trail for use in post sprint and post project evaluations and to avoid the “that’s not what I said” syndrome that occurs when the only communication is oral.
If, as the project progresses, new user stories are identified, then they go through a change control process. Why? Because any significant change in scope needs to be managed to avoid scope creep - the incremental and unconscious expansion of scope. Why avoid scope creep? To make sure that stakeholders understand and approve changes in schedule and cost that result from changes in scope.
As the project progresses, review each sprint's performance. Were sprint estimates accurate? What factors led to schedule variances? Were there too many user stories for the sprint? Too many changes? Unavailable customer representatives? How can remaining sprint estimates be adjusted to make them more accurate? What impact will those adjustments have on the overall project schedule and costs?
Managing Expectations
Whether the project is planned with a traditional approach or is agile, there is a need to manage stakeholder expectations with an incremental approach and iterative refinement. High-level project estimates are needed early in project life so that go/no-go and budgeting decisions can be made in the context of strategic planning. Expectations are set so that the stakeholders understand that there may be significant variance between optimistic, most likely and pessimistic estimates.
As a solution architecture and high-level requirements are identified and documented, the estimates are refined. If you are taking a traditional approach, engage the developers and prototype instead of describing functions in text and unrealistic mock-ups. In other words, become more agile and start to blend detailed requirements definition and functional design with development.
As development takes place, monitor and control to assess performance and refine the plan based on your results.
Use incremental, iterative plan refinement to ensure that expectations are realistic.
Questions or comments? Feel free to share them below!
You may also like:
ABOUT THE AUTHOR: George Pitagorsky, PMP, integrates core disciplines and applies people centric systems and process thinking to achieve sustainable optimal performance. George authored The Zen Approach to Project Management and PM BasicsTM. He teaches meditation and is on the Board of Directors of the NY Insight Meditation Center.