Agile PM for non IT projects

In our search for delivering projects better the use of an Agile Methodology is one of the latest in PM practices and ways to?optimise project delivery. With its different perspective on locking time and cost it can offer benefits to projects where requirements may not be fully known at the beginning or where you can flex the building blocks of the final solution. Most often it is talked about in the context of a software development project however here are some Agile practices that you can apply on your waterfall project which scope:

Incremental or Early Release.?In a construction project this is known as early works and represents parts of the project scope that we can advance ahead of the final product. This could be removing trees in the way of a rail corridor or delivering one equipment set to a military platform ahead of the full project scope. Advantages are that we start to deliver benefits to the end user earlier or reduce the risk for when the final product is released.

Scrums.?Where you have a long or complicated task that can’t be fully defined upfront we can utilise the concept of scrums whereby a set of the requirements are worked on first. These could be the proverbial low hanging fruit that are required before we get to the more difficult items. An example could be a complicated set of documents with multiple parties working to complete them that is estimated to take many months. We can section the document or task and then assign points for each section which equate to effort. With a rough estimate of these points we break the planned delivery of months into weeks with a number of points per week. We then drive the team to deliver a certain amount of points per week with the advantage?that we don’t need to rely on a Gantt chart to tell us how we are going, On a task such as this a Gantt?may only tell us everything is being done in parallel. Another advantage is that we avoid the mythical man month where a task takes as long as there is time available.

Evolving Requirements.?This practice is where we don’t develop the detailed requirements until the latest possible time and aims to avoid rework when we do know the full requirement set. An example is for a new product?that is so different from how the business works today that the business team can’t envisage what good can look. So we provide the cheapest, smallest piece of value to the business for them to start to understand. In practice this can be site visits to other users, demonstration equipment, trial sites or prototypes.

Avoiding a Gantt.?We all love a schedule that is nicely?detailed, linked and resourced however when we get to a very detailed level 5-7 schedule it can become cumbersome and not reflective of reality. A job board where you have the tasks required to be done and their status can be far more effective as it gives everyone a quick snapshot of task status and also any blockers to tasks. Advantage is that we don’t spend our time trying to create a set of logic links and tasks with a predefined execution path. If you can’t easily detail a set of predecessors and successors it is likely a Gantt won’t provide you value on your set of tasks at the detailed level.

?This is an active list that will be updated as we discover more items that you can take from Agile where a full Agile implementation may not be suitable. We hope that you enjoyed it.