Use repeatable elements
An ad hoc approach to the project takes too much energy and resources, and always runs the risk of missing some of the necessary elements. The best way of simplifying what has to be done is to use repeatable elements, and preferably to take them in repeatable cycles.
Example: Quality checklists
A checklist is a simple example of a potentially repeatable element that many people use in their personal and professional lives. Take quality criteria of a deliverable, for instance:
- First, you may create a checklist of all criteria, which is a form of planning.
- What NUP6 recommends is to try to generalize it: are there other similar deliverables in the project? In that case, prepare a general quality checklist for that category of deliverables and use it for all of them. If there are some variations, keep the generic list, and add a few extra items for the individual deliverables. Now you have repeatable checklists.
- Once you have prepares generic checklists for various types of deliverables, you may find elements that repeat among them, which suggests a virtual parent category for them. In that case, instead of repeating the items for all those generic checklists, you can extract them and put them in a parent checklist. In the end, you will probably have a single generic checklist for the whole project. Scrum’s “definition of done” is an example of using project-level checklists for quality (possible among other things). By doing this, each deliverable will belong to a hierarchy of categories and should satisfy the items that appear in checklists of all categories in their chain.
By doing this, an item in the parent checklist will become repeatable for all deliverables underneath it, which saves time and energy in planning and execution.
More importantly, once you do this for one project, you can tailor and use it for all similar projects in the future, which is a repeatable form of planning for multiple projects.
Example: Processes and workflows
Some deliverables, or goals linked to them, need certain steps that can become standardized and repeatable. For example, if the deliverables need to be designed individually and approved, you can prepare a simple workflow that makes all the steps, people involved, and approximate durations clear, so avoiding many difficulties. You should be careful, however, not to make the workflows and processes too complicated or too intensive in documentation, as it will have a negative consequence. All people involved in the project should see the workflows and processes as something that supports their work and makes everything easier for them, rather than as bureaucratic documentation that blocks their real work.
Agile projects have repeatable elements in their iterative development approach, where certain type of development activities are repeated for every feature; e.g. the common daily routine in XP (eXtreme Programming): pair up, pick an item, design it on a whiteboard, build the test scripts and code, integrate the code, etc.
Beside the repeatable workflows that can be used for technical activities, you can have repeatable elements for the project management activities as well. The processes in the PMBOK® Guide, PRINCE2®, and DSDM®, the activities in P3.express, and events in Scrum are examples of this concept.
Having repeatable elements for managing the project is helpful. This can be made even easier by putting them into repeatable cycles. These cycles significantly simplify the day-to-day activities of people involved in the management and leadership of the project. Cycles of process groups in the PMBOK® Guide when used in a project with multiple phases, stages in PRINCE2®, daily, weekly, and monthly cycles in P3.express, iterations and timeboxes in DSDM®, and Sprints in Scrum are all examples of this concept.
Shorter cycles are easier to understand and use than longer ones; e.g., Sprints in Scrum in contrast to the phases according to the PMBOK® Guide. However, cycles that are too short may not be enough to support certain types of project, and the solution can be the use of multiple cycles, such as DSDM®’s use of short timebox cycles along with longer iteration cycles, or P3.express’ use of daily, weekly, and monthly cycles.
Using a methodology or a framework for running a project is another use of repeatable elements. This can be an existing system such as PRINCE2®, P3.express, DSDM®, or Scrum, or one that you’ve customized or built yourself. However, it’s normally a better idea to start with one of the existing methods and adapt it to your needs than to build it from scratch.
Any repeatable element is abstract and needs customization to adapt it to the real world. There’s a spectrum of abstraction and need for customization, though: small, relatively concrete quality checklists are at one end of the spectrum with the least amount of abstraction and need for tailoring, while methodologies are at the other end, with the highest need for tailoring. You should always note the need for tailoring, otherwise, the repeatable element won’t match your needs properly.
NUPP is open-source and published for free under a Creative Commons license.
Written by: Nader K. Rad