Is project scheduling and reporting dead – or has it just changed shape?

Is project scheduling and reporting dead – or has it just changed shape?

The move from the traditional ‘waterfall’ project management approach to an Agile approach is often seen as a choice of managing a project one way or the other. Project scheduling and reporting activities are associated with Traditional project approaches and are often listed as “not required” on agile projects.

The reality is that in both Traditional and Agile approaches the key activities which would be undertaken to plan and monitor a project either would not vary greatly or would not change as much as you might think.

So, what are the key activities of this role?

1. Planning, and

2. Monitoring.

It’s that simple.

Consider what needs to be done to establish and manage the progress of a project. Once these four key activities are described, I will discuss the similarities and difference of both Traditional and Agile approaches – I think you will see there is far more overlap than you might have thought.

1. Identify what needs to be done and record it somewhere. (Planning)

This is the ‘what’. Remember the old saying, “you can’t manage what you can’t measure”?  So, you’re going to track the building of a house. In a four to six-month project when would you know if you are off track? After a month, or two? No, you will need to decompose that broad “build a house” task into a number of sections and sub tasks – down to a level which allows the team to pulse check progress. In most projects that check would be conducted on a weekly basis.

Once you have the ‘what’ you need to ensure this is properly recorded:

• in a traditional project this would be recorded using a tool such as Microsoft Project, with a well-defined Work Breakdown Structure (WBS) and trackable tasks. The tasks are only trackable by estimating the level of effort and applying actual progress in Step 4. You may choose to call out key phases such as Analyse > Design > Build > Test etc, but there is no rule that says this ‘waterfall’ approach has to be adopted just because you are running a ‘traditional’ project.
• in Agile projects this is often recorded using a tool such as Atlassian’s Jira. In Agile this information in most cases would be segmented into Initiatives (projects) > Capabilities (measurable outcomes), Epics (groups of activities usually based on a project stream) and User Stories (which record estimated work effort using Story points).

Similar or Different?

A: Similar

So, in this stage we are simply identifying activities, and recording them in different tools. How this is actually done is similar in both approaches, usually by identifying and engaging stakeholders, and conducting workshops and meetings to tease out the work required to complete the project and then ‘unpacking’ them into smaller, more manageable, more measurable tasks.

2. Test for doability and feasibility. (Planning)

This is the ‘how’. Sure, we can build a 100m fence in a week, but to make it doable I’ll need multiple workers, and will have to schedule/sequence the tasks – you can’t put on the panels until the rails are up, they can’t be attached until the posts are in (and the concrete foundation set), and so on.

Once you have the ‘what’ we then need to ensure work is sequenced in order to ensure what is required by the team is available when they need it, and that resources are not over allocated. If there are unrealistic expectations of the people who are needed to complete the work then the project will fail.

So how is this managed in both approaches?

• Using a traditional project schedule the team would ensure that work is sequenced and relationships enforced using (typically) finish to start relationships. This way any changes made can be assessed for any impact to other project activities.
• Using Jira in the Agile world, the team use the concept of a short (between 2-4 week) Sprint to keep a very close eye on work in progress (WIP). Agile expects change, so the focus on doability is making sure work being moved into and out from the Backlog (to manage scope changes) are like-for-like changes (no scope creep).

Similar or Different?

A: Similar goal/ different approach.

One of the guiding principles of Agile is ‘accepting change’ – I believe this is one of the many strengths of this approach.

3. Think how this information is to be consumed. (Planning)

   This is the ‘message’. Too often the way the team communicates with stakeholders such as the Executive is an afterthought. I think it is vital to get the picture up front which can be presented to a steering committee and which has the right level of detail, based on tracked activities as determined in step 1. Is the message going to include key milestones, risks, blockers? Once this is understood then the deeper detail can remain out of view for those who do not need to ‘dive into the reeds’.  For multiple teams working together, right at the outset there will need to be agreement on what and how you roll data up to create the picture your stakeholders need.

Similar or Different?

A: Identical – whether you are using Dashboard/Reports /Showcases you will still need to answer the questions your management will ask about progress and status.

4. Baseline to detect early variation to planned progress. (Monitoring)

   When do you want to know you aren’t going to deliver this Friday at 5pm? Friday at 4:45pm?, or the previous Monday at 9am? I’m pretty sure we would all agree that early notice of risk to delivery gives the team time to consider options to bring the project back on track, make and submit recommendations AND (most importantly!) give management time to make a decision on the best option.

So how is this managed in both approaches?

In the traditional approach, a scheduler would meet with team members and ask two questions:

• How much work have you done on the task? And
• How much work is left to finish the task?

This application of actual work allows the scheduler to determine if a task is running behind. This then allows some ‘what if analysis’, and, in particular, lets the scheduler look at the impact this delay might have on the critical path (the series of tasks which define the length of the project). Where there are impacts, then options should be considered and presented to the project management team for consideration.

In Agile, you would be asked the same two questions, but the focus on the WIP during a sprint and the ability to move items in from and out to the backlog means very strong short-term management of tasks.  Mechanisms must therefore be put in place to detect more distant change. Using Jira, a ‘watch’ can be placed on an item (such as a User Story) which automatically alerts (via email) someone monitoring the item where, when, who and what changes were made to the item. This can then be assessed just as is done traditionally.

Similar or Different?

A: Different

This is an area where the application of actual work is different in the approaches, however, the means to provide this early warning, though different, can still provide the same outcome.

Summary

The way a project is planned and managed (from a monitoring perspective) is very similar in both traditional and Agile approaches, the key point to call is that understanding the principles behind good planning and monitoring will allow you to achieve best results no matter which method is chosen.