- To be valuable, scope must test at least one hypotheses.
- Projects are an exercise in exploring uncertainty.
- This often includes hypotheses on budget or schedule.
- Can a given sum of work be delivered for x expenditure?
- Can a given sum of work be delivered in y amount of time?
- It can also be a technical hypotheses.
- Can a given sum of work be delivered in z way?
- It can also be an end user centric hypotheses.
- Does user experience a meet users or stakeholder needs?
- Is it optimal to some criteria w?
- Of course, all hypotheses are end user centric hypotheses.
- End users can value budget, time, technical approach.
- End users can value adoption or a specific experience e.
- End users have relative priorities across what they value.
- These priorities can be internal and external to the people and organizations involved.
- Project managers have relative priorities across end users.
- An end user can be someone using the project to meet a strategic or tactical goal even if that end user never uses the specific sum of work in a project as an operator.
- There can be a perceived conflict between Agile and Earned Value Management around scope.
- Agile and iterative development approaches often identify scope as being evolving.
- This evolution comes through continual and ongoing planning.
- This particularly happens through evaluation of sums of work delivered quickly, facilitating rapid testing of the hypotheses in that scope.
- There is a perception that scope is fixed in Earned Value Management approaches. That by defining a predicted budget and schedule for a given sum of work the practitioner is fixing the scope. Or, for that matter, fixing budget and schedule.
- This is not true.
- Scope remains a hypotheses under EVM approaches, as does budget and schedule.
- The misperception may arise from the explicit intertwining of scope, budget and schedule.
- This occurs and is documented in artifacts often without an explicit recognition of the uncertainty inherent in projects.
- The uncertainty is there none the less.
- There are artifacts and approaches that document and explicitly recognize the uncertainty. These are artifacts around risk management, probability weighing and scenario planning.
- Agile approaches may skip the explicit risk artifacts, relying on less explicit recognitions of uncertainty. Or, relying on the recognition of uncertainty inherent in the philosophical or historical underpinnings of Agile or iterative approaches.
- One difference may be the threshold for accepting or rejecting hypotheses. Or the insistence on A specific hypothesis or set of hypotheses in the face of evidence or the given amount of evidence required to reject a hypothesis.
- Why some people are locked into a specific hypothesis for too long.
- This takes us deeper into the sociological and psychological and neurological elements of a project
- Not to mention the general orientation towards uncertainty of project participants
- Either way, uncertainty is there.
- Projects are an exploration of uncertainty.
- Scope always tests at least one hypothesis.
- The number of hypotheses is related to the number of people involved in completion of the sum of work.
- This includes end users, stakeholders, funders and people explicitly producing the sum of work.
- The more explicitly we recognize and discuss these elements the more likely we are to have clear communication around scope, budget and time, as well as clear communication around expectations.
- The success of a project is based on the clarity of communication around and within the project.
- Success
- Explicitly testing specific hypothesis around a given sum of work
- Explicitly communicating the hypotheses being tested and
- Understanding which hypotheses to test and when
- All lead to better communication and more successful projects.
- The amount of uncertainty in a project never goes down.
- What changes is the amount of communication and shared understanding of the uncertainties involved.
Reinventing Communication 
Comments are closed.