Customers Want to Know Current Project Progress
When you are the customer and you are spending significant amounts of money on a project you want to know as much as you can about the project. When you do the work yourself, you know the status as you go. If you’re hiring a contractor to do something, you want to know:
- Why you need the work done (the big picture)
- What work they will do (scope), often broken down into small enough chunks to follow the progress
- When will they do the work
- How much they will charge for the total project (cost)
- How well they will do it (quality criteria / requirements)
- Who is doing the work
- Check: How is their actual performance against their committed performance (this is the “C” in PDCA)
You do not want to wait until the end and find out if the contractor did it as expected or not. Now that we’ve started with being the customer, let’s switch to satisfying a customer with a customer focus.
Customers want similar insight about a training product development project from us. Some customers have their own expectations for how we have to provide information about project progress. It may seem that they want control, but often times they really want visibility. Many of their expectations come from traditional project management approaches, and not Agile Lean project management approaches. A Kanban board can help provide that visibility if they don’t have a specific format they already use.
Gaining Alignment Up-Front for Visual Progress Reporting
Part of the up-front expectations alignment that needs to occur before beginning work is gaining agreement on how to keep up-to-date on what is happening in the project. If you leave this unaddressed, the customer tends to assume you will meet their expectations. This is especially important if your customer’s boss or stakeholders expect traditional update formats for progress reports to them. If you want to convince them that Agile Lean project updates can meet their needs, it helps to provide an example. Those with roles in charge of customer relationships may not want to open up this much information to the customer when they are used to only showing the schedule Gantt chart
Typically the traditional folks expect a Gantt chart showing the milestones with their various dates in columns from left to right. Cost is typically agreed in documents beyond the Gantt project and sometimes not known to the project team.
- Published version of Gantt chart
- Milestones listed in task column to left of Gantt chart (scope)
- Forecast Start (revised when)
- Forecast End
- Baseline Start (committed when)
- Baseline End
- Actual Start (real when)
- Actual End
- The difference between baseline dates and actual dates lets stakeholders check actual performance against committed performance
- Who is accountable (a “resource” in MS Project) for each work item can be listed on the Gantt chart
- The update frequency may be weekly, biweekly, or monthly by some process to get the data from the accountable resource to the person in charge of the Gantt chart file.
- Some Gantt chart revision scheme has to be agreed between the parties so that all parties reference the same published revision during “update meetings”
- Some organizations expect a 15-day or 30-day look ahead that shows milestones coming
- The Gantt chart may be accompanied by a Design Document (the big picture)
Agile Lean Approach
Often Agile Lean teams and stakeholders are coached to expect the following.
- Kanban board
- Columns start with Backlog (To Do) on the far left of the board
- Columns end with Done column on far right of the board
- Columns in the middle are labelled as the process steps (e.g. analyze, design, develop, pilot) flowing from left to right
- Ready queue columns are added before every process step column
- Sticky notes representing the work items are placed on the board where the progress is (what)
- Who is accountable for each work item is visually represented by avatars, initials, or names
- The update frequency is daily by the accountable person (decentralized)
- There is no need for a revision scheme. The board shows the status every day
- The board shows the committed work items for that iteration their current column (e.g. backlog, process step), indicating the performance to date
- An iteration burn down chart can show progress against expected
- Blocker visual signals let people see an abnormal situation exists
- You may need additional licenses if using virtual Kanban applications, or customer access to your whiteboard if using physical Kanban boards.
- Everyone looking at the Kanban board has a project perspective similar to a traffic helicopter seeing the highway traffic flow from the air, easily seeing where everything is at a glance
- The iteration backlog only shows the scope of work items that are intended to be completed during that iteration (the rest are in the courseware backlog)
- The iteration is a fixed time box of two weeks, telling stakeholders when
- The Kanban board includes or is accompanied by a so called “burn down chart” that includes predicted end date shows when for the entire courseware product (in the event some work items are not completed during their iteration as committed)
Visual Progress Avoids Some Problems
If you get the customer to agree to using a visual progress method like a Kanban board then you can avoid some problems that occur in traditional projects like the following.
- The key person that tracked the project progress on a spreadsheet that was only stored on their local drive was not back from vacation yet and did not answer their phone and the customer update meeting proceeded without them. A visual progress method would have allowed the team to look at the Kanban board and see where the progress was from before the holiday break.
- The customer has rev 3, but your team is using rev 4 of the Gantt chart, frustrating the customer. All looking at the same Kanban board removes this problem.