Delivering the promised scope at the agreed time is the top priority for projects. But how do you deliver on this target? Of course, in some cases, a scope shift is justified and can be attributed to unforeseen changes to the project requirements – e.g., if market conditions or corporate strategy changes. However, it is important to realize that more often than you might think, changes to the project scope are not based on a deliberate decision but are due to a shift in the political balance of power, a lack of consistency, or insufficient planning.
This is an interesting phenomenon, which organizations seem to forget in the wake of project promises. Unfortunately, this lack of consistency often has little or no consequences for the people involved and is hardly ever noticed, although it can have severe repercussions for the enterprise and undermine its ability to execute midterm and long-term business strategies.
We, therefore, urgently advocate tracking key facts over the entire project life cycle, including major goals, high-level requirements, key architectural decisions, financial impact, and milestones.
This may sound a little old-fashioned or even bureaucratic, however, we must accept a pinch of formalism to ensure the delivery of intended results and traceability. A change of direction should thus always be a conscious decision. Especially if you are using agile techniques to achieve maximum flexibility, it is imperative to track key decisions and changes of direction rather meticulously.
What Concrete Actions Do We Propose?
Firstly, the documentation of the key facts must become a mandatory project practice. This is the basis for ensuring that all stakeholders can be involved in important decisions and that the work of the project team is comprehensible and verifiable for people outside the project team.
Make the documentation as lean as possible
Distinguish clearly between key facts and other documentation items. It is critical that the scope of the documentation is as lean as possible – e.g., comprising major goals, high-level requirements, key architectural decisions, financial impact, key facts, and milestones.
Select a language which combines precision and ease
Natural language is often not precise enough. When project portfolios get big, unstructured text is too unwieldy and doesn’t allow for tracking dependencies and causality. At the other end of the spectrum, typical IT people languages such as UML, BPMN or Archimate are too difficult for outsiders to understand. Therefore, you must find a fair compromise – e.g., a simplified subset of Archimate or UML combined with role-specific presentations like simple lists and tables.
Establish a centralized document storage
Provide one central location for storing and managing the documentation. Additional documentation can be placed in special repositories. However, the key facts must be stored together in one place.
Define governance touchpoints
Define a few simple governance touchpoints – also called quality gates. For example, “project candidate”, “project sign-off”, “planning” etc. The base for the reviews at these governance touchpoints must be the centrally stored documents.
Extend the documentation incrementally
Gradually expand the documentation from milestone to milestone. For example, assume that you have delivered project goals for the milestone “project candidate”. The next step is deriving business and IT services impacted by the project for the milestone “project sign-off”. Furthermore, use cases are a good level of abstraction which help clarifying the scope for the milestone “planning”.
Note: this approach is of crucial importance, especially in agile projects. Here, autonomous teams‘ decisions are guided by the strategic goals. In this regard, agile methods require a great deal of discipline.
Ensure full transparency
Make all documentation available for everyone. No secrets!
Educate your organization
Ensure that the entire organization can read, understand, and contribute to the documentation. This is where the simplicity of the underlying documentation language as well as the lean scope is important. You must ensure that the skills to handle the key documentation can be acquired in a few hours of training.
