Your browser is unable to display this site correctly. Please try an up-to-date version of Chrome or Firefox instead.

< Back to all posts

"Social" Status Reporting

Jeremy Chan

By Jeremy Chan


View bio
December 01, 2011

Whenever we procure services from a vendor (e.g. remodeling a kitchen), we are faced with overcoming the fear of potentially spending a lot of money without getting a successful result at the end. This is especially true when the total budget for the project is not fixed. We attempt to overcome this fear by performing our "due diligence" before hiring the vendor, which amounts to evaluating the vendor's record, stability, cost, and references, and generally developing an overall trust relationship sufficient to allow us to "take the plunge".

Once this decision is made, however, our control over the project drops sharply, and our visibility into project progress is then limited to what we learn from the vendor's status reports, and what we see as visible progress.

Unfortunately, we never really know if the vendor - as a matter of either "not knowing" or "keeping themselves out of trouble" is painting a rosier picture than reality might reflect. Also, it's often the case that visible progress is not easy to come by (especially in the early stages of a project). This is especially true of software or web development projects, in which the work product is so very abstract until it can actually be used.

So our visibility goes down, our stress levels increase, and we begin to spend our time standing on the vendor's head nervously polling "how are we doing?" every day or two. Since Jonah Group is a services organization, we understand this dynamic all too well, and use two major strategies to prevent this from happening.

So our visibility goes down, our stress levels increase, and we begin to spend our time standing on the vendor’s head nervously polling “how are we doing?” every day or two.

The first is Iterative Development and Delivery of vertically integrated pieces of the system (stories or use cases). I won't go into this very deeply, because it is a well-developed, well-understood technique at the centre of modern Agile software development methods. Essentially this reduces risk by delivering working pieces of functionality early and often so that visibility into progress is re-established at discrete points in time (typically the end of each code Sprint).

The second is the process of continuously collecting answers to the question "How much time do you have remaining on this task?" from each of the team members, aggregating this information in real-time and sharing it with the team and the client. But how?

This might be done once a week or once a day in a roundtable with the team in which the Project Manager or Team Lead asks that question while everyone else wishes for the moment that they can just exit the meeting and get back to work. A good PM will then take that information, collate and analyze it to try to detect schedule variances at an aggregate project level, and then report these back to both to the team and to the client early on to set appropriate expectations, and to initiate any course corrections that may be required.

This analysis is such a time-intensive task, however, that most PMs don't bother to do it. And when they fail to do it, they begin to lose control of the project. As visiblity is slowly garnished, the PM adopts the same nervous pose as the client at the start of the project. Stress levels increase, and he or she begins to simply hope that things will work out with some magical combination of pleading and whip-cracking.

`Knowing when the task is projected to be over budget is much more useful than knowing when it actually is over budget.

Two things are important to note, here.

  1. the act of delivering an estimate for the effort remaining on a task is important in and of itself:

    • It forces the implementor to think about what is really required to complete the task.
    • It engages the estimator in an unwritten contract that they will do their level best to meet since they were the originator of the estimate. Before this point, he or she is at liberty to shrug off an "over-budget" or "late" variance by denying responsibility for the estimate.
    • It helps them to become better estimators, by becoming more aware of what types of things cause difficulties, and how long it really takes to do something that initally looks relatively straightforward.
  2. The act of tracking the variances relative to the estimate is also important in and of itself:

    • It motivates individuals to work more efficiently in order to meet their targets - team members don't like to disappoint each other.
    • It gives the PM (and thus the client) early visibility and feeback as to how the project is doing.

The daily stand-up meeting found in the Scrum method is an attempt to address most of these items, but it requires a boring daily meeting, in which the entire team listens to what each person plans to do that day, and how long they think it will take. While this does provide certain obvious dividends, it can also sap productivity. Also, the historical record of the team's individual and aggregate estimates is lost forever, because it is never captured in a system. This record is an important tool in helping teams conduct useful retrospectives about the quality of their estimates.

The juicy part of the daily stand-up meeting is the discussion of progress blockers, in which team members can help each other with suggestions for solutions. In my view, the status reporting portion should not be done in the full team meeting for two reasons:

  1. The PM will have to spend too much time analyzing the status information in order to be able to make any useful predictions from it
  2. The team will have to waste time sitting through status reports which are largely irrelevant to them, because they have no explicit mandate to drop their work and help another team member past the blocker that is potentially causing them to be behind schedule. The PM or team lead can give them this mandate, but the decision as to what makes sense to change is informed by the results from the analysis from reason 1.

All of this points to the need for an automated system to continuously collect and report on status - in particular "how much effort remains" and "when will it be complete"? At Jonah Group, this is implemented in our project management and time-tracking system - Lychee. In this system, developers can estimate and record both the effort they spend and the estimated time remaining whenever they work on a task. They can also continuously update this estimate as things change. This is important, because an estimate that is allowed to change prevents team members from immediately become disconnected from the plan whenever there is a variance from the original estimate.

The tracking control is used to browse through the hierarchy of tasks in the plan, giving everyone on the team (including the client) access to real-time status information. The meter on the left shows the hierarchy of tasks in the context of the time schedule, and the meter on the right shows the status details for the current task. Take a quick look tour of our tracking meters below (click on the diagram below and mouse over the individual elements for helpful descriptions).

[Lychee Project Tracking Meters]

The linked page above provides a static view of the tracking meters, but in fact they are very interactive. One can navigate the hierarchy by clicking on the arcs on the (left) task hierarchy panel. This allows accurate status information to be displayed at any level of interest within the project task hierarchy. The current task is always shown on the (right) task detail panel. Finally, the task feed is available below, which is pulled from the timesheet comments.

Of particular importance are the coloured wedges on either meter - they reflect the current projected completion date (on the left) for the task at hand if work on it were to start immediately, and the projected total effort that will have been spent by the time it is completed (on the right). Knowing when the task is projected to be over budget is much more useful than knowing when it actually is over budget.

These calculations depend on regular collection of time-remaining estimates on each task, which our system allows our team members to do.

Here is a dynamic view of the control, which will give you an idea of how the system works.


We give our clients access to these tracking meters so that they can have the same visibility into status throughout our projects as we do. This level of access to "how the dog food is made" is one they can't get from any other vendor. Sometimes this puts us in an uncomfortable position when things aren't going as smoothly as planned, and we have to answer difficult questions about why. But our philosophy is that the discussion is a useful one, which needs to occur in any case, and we don't believe in leaving our clients out of the conversation.

Real-time progress tracking reduces risk by allowing a team to react early to plan variances. The Lychee project management system provides a mechanism to allow this to happen efficiently on both the input and reporting sides, freeing teams from having to collect and discuss this information during status meetings. All of this reduces the stress levels in both the team and the client, and makes for a more successful project overall.

About Jonah Group

Jonah Group is a digital consultancy the designs and builds high-performance software applications for the enterprise. Our industry is constantly changing, so we help our clients keep pace by making them aware of the possibilities of digital technology as it relates to their business.

  • 24,465
    sq. ft office in downtown Toronto
  • 160
    team members in our close-knit group
  • 21
    years in business, and counting