Insight # 48 : Time for a Change of Gear: Partnering to Deliver Success

Succeeding with Data-Guided Decision-Making

by Catherine Pye

This government agency sought a better way to justify its budget allocations, manage projects, and make resourcing decisions. Capturing key data has helped change the way the department operates on many levels.

For the last five years Pcubed has partnered with a medium-sized department within the Australian Department of Defence. This organization delivers huge programs for external partners within Defence as well as smaller internal projects for its own operations. It was routinely given budget for performing work for its partners, but it lacked rigor around how it was delivering on those projects. Schedules were running overtime while budgets were being underspent, a big sign that something was missing. Members of the department's leadership were dissatisfied with status quo and wanted to deliver better against their plans.

Initially, Pcubed was brought in to implement Microsoft Project Server, an enterprise tool set for improving the transparency of the department's project management and centralizing its activities. The goal was to gain a consistent way to produce status reporting, manage risks, track issues, and stay on top of budgeting.

But as is usually the case, simply installing new software wasn't enough. The organization needed to recognise that they required a multifaceted change management journey in order to fully exploit the functionality of Project Server and achieve the benefits they had targeted.

In this article I share lessons learned from this engagement about the power of data to change behaviours.

My First Gaffe - and Gaining Early Converts

The first hurdle we had to get over was convincing people to put their project data into Project Server. At the time we came into the project, project managers all used their own approaches - Microsoft Project in a few cases, but often spreadsheets, sticky notes, and email formed the foundation of their management approach.

On my second day on the job, I went to talk to one of the "elder statesmen," a project manager who'd been with the department for a long time and had an extensive history of experience with government projects. I sat down and gave him my pitch: "I'd like to talk about transitioning your project information into Project Server." He looked at me with a frown and said, "I've been doing this for 25 years across three different continents. Is there anything you think you could possibly teach me about project management?"... I don't think I will ever forget those words.

Somehow I'd had the notion that I should start with the "hardest" convert first, somebody who had defined practices and knew a lot about the business. While this had been a blunder on my part, it also provided me with a clue. He wasn't going to take my word for it; he'd need to see evidence of the benefits before he'd consider change.

That was indicative of the sentiment we'd see throughout the organization. Anecdotes about successes weren't going to be sufficient, nor were sales pitches. These project teams were only going to come on board when they could witness a dramatic change and see how the solution would improve their situation. So the change management approach we needed to use called for us to focus on metrics.

I told the "statesman" I'd come back in a few weeks when I had examples to share.

During the next month, I approached many other people - seeking out those who were newer to project management and less wedded to particular methods of working - people who hadn't been "burned" by having used 10 different project tools in just as many years. They tended to have smaller projects and could provide the "quick wins" I was seeking.

By the time I approached that original target again, we had 20 other projects from across his area loaded into the system, and I could show him how the information would look when it all came together into a working format.

Those pioneers also served as advocates for us. His own colleagues were the people using it who could say, "Well, this has made it much quicker to produce a status report. Instead of two days a month, it now takes less than half a day."

Ensuring Data Quality

A crucial part of this initiative was getting useful reports to managers and executives. There were middle managers who were managing down to make sure projects were functioning. There were also senior executives reporting back to the Cabinet level to provide the information government needed on how money invested in these programs was meeting strategic objectives.

But good reporting required good data. This organization invested well to sustain their early momentum. In order to ensure that quality data was being added to the new Project Server system, Pcubed took a number of steps. First, we worked with the project managers closely. The dedicated project management support role proved critical in not only prompting Project teams to enter data, but to also help them adopt it as a management tool - replacing their spreadsheets and Outlook tasks with tools specifically designed to support them in the management process. Recognizing that putting in a new technical solution isn't the end of the implementation, they also allocated a dedicated technical support manager who could maintain the environment and tweak the reports as users began to consume them and also provide new or additional requirements.

Pcubed also built workflows so that status reports would be automatically submitted to project sponsors as well as key business partners - the representatives of the business who had previously struggled to get current and informative reporting. This was an important step in engaging the business throughout the development of their capabilities.

Getting those sponsors to back the initiative was invaluable because it improved the data quality. Without continual encouragement, people inevitably revert to their comfort zone - keeping track of their projects on spreadsheets, on sticky notes, or the like. And the Project Server data would get out of sync quickly. As soon as that happens, the reporting pulled out of the system isn't valuable. If the sponsor is asking, "Why isn't this status report in the system?" that carries more weight than a project management office or business manager or consultant saying it. All it took was for the executives to stop accepting spreadsheets or manually collated reports and to demand the enterprise reporting coming out of Project Server. This is an ongoing challenge - it turns out executives require as much support as project managers.

Quick Response Risk and Issue Management

I acted as the project management support person in the early days. I had a desk among the project managers, and I would sit with them to review their schedules, help them update risk logs, and attend their stakeholder meetings to introduce the use of the technology. That helped me to become part of their "every day," allowing me to stay on top of latest project pain points or development across the department. As they became accustomed to my presence, their confidence grew that I knew what they were talking about and what they needed to achieve success in their projects. Then when they'd raise problems, I could respond in context, and we could shape the solutions around their reality, rather than take an off-the-shelf approach.

One area of education was risk and issue management. Prior to implementation of Project Server, project managers might enter a risk into a log, but it would often be forgotten and then reviewed (i.e. closed) when the project was closing out. When an issue would arise, the connection would be lost between that issue and the risk that had been recorded sometimes months earlier. Here's where the technology shined. We wanted PMs to start raising potential issues to the person who actually had the power over money or scope or schedule in order to put some mitigation in place.

The reporting work included development of an escalation function where the PMs could click a button in their risk or issue log and automatically have the issue escalated to their section head's attention as something outside of their control. The section heads had a single-page view with cumulative data for all of their projects. From there, they could drill down into the project to see the details and look for patterns or relationship between individual project risks and issues. If the status of a project was red, they could click on the indicator to be taken directly to the problem. What this did was get them involved in issues earlier in order to address small problems before they could become big ones.

Plans versus Reality

Once project status and forecast reporting was under control, we began to focus on timesheets. This would help us get to the heart of understanding why projects weren't being delivered on schedule.

Initially, the project managers would assign generic resources to their projects. Once the project was underway and they'd know who was actually doing the work, they had the ability to go back in and assign a named resource. While named resourcing provides significantly greater control for both planning and delivering, it requires more investment in the administration of the schedule. This surfaced a new issue for the organisation as it struggled to define where the role of implementation manager lay. This was a problem that would manifest time and time again in the environment of human resource scarcity.
 

The timesheet feature at its most basic allows people working on a given task in a project to record how much time they were spending on it. But in order to get the whole picture of what staff was doing, we didn't limit it just to projects; we had them planning and timesheeting all of their work. That might be a project, or it might be sustainment tasks - work dedicated to keeping up systems - or operational tasks - the business' actual objectives and the ordinary, everyday work that kept the department running.

They didn't know how much time they were supposed to be working on any one task
and a scarcity of resourcing meant they prioritized break-fix over new capability.

Initially, the department assumed that it had about 25 percent of its full-time equivalents in a particular branch working on projects. What we found after one year of collecting data, however, was that these people were only spending about five percent of their time working on projects.

In many cases, staff members were spending the bulk of their work hours on sustainment projects. They simply didn't know how much time they were supposed to be working on any one task and a scarcity or resourcing meant they prioritized break-fix over new capability. For example, somebody might be sinking hours into a reporting project that would benefit only a couple of users while a project to replace the capabilities for 500 users was falling behind. The perception was that sustainment always came first. You fixed whatever was broken, regardless of the priority of the project.

Suddenly, the data revealed to us why projects weren't being delivered on time. In response, the department renewed its focus on stripping back its legacy systems to eliminate some of that sustainment overhead in order to free up resources for work on projects.

The process of timesheeting wasn't without its challenges. Essentially, people didn't want to do it. Because they work in a closed environment, they weren't used to talking about what they did let alone consolidating a list of all of the things they were doing in their jobs. With time we were able to demonstrate our commitment to people that the information wasn't tied to lone individuals; the data was secure and it was being used in aggregate with nobody being singled out. "Big Brother" wasn't looking over their shoulder. Some of that pushback also evaporated through personnel turnover. As new people came into the department to replace those who had moved on, timesheeting was simply a part of the requirements.

As we sought change, we learned just how important management commitment was for ensuring success. While some leaders had a tough time accepting what the data was telling them, others instantly understood the impact and doubled down on their commitment to the use of Project Server. Some branch executives added compliance targets to their team's professional development targets. The value of this was easily identified through one particular example. When one executive who was a strong supporter moved on, we saw compliance from the team members across their branch drop from 94 percent to 74 percent within five weeks.

Some Big Wins

While the timesheet initiative is still going on within this government department, we can point to several wins.

A big one is acknowledgement that anecdotes don't challenge culture; metrics do. Managers have learned that there's no point in going to a branch head and saying, "I need five more people because all of my people are overworked, and we can't do all the work we've been assigned." However, if they can go armed with data and say, "I've been allocated 600 hours of work per week, and I've only got enough staff to do 400 hours of work a week," that makes a stronger business case for getting the additional staff that are needed.

Another win is that the organization has improved its project planning to give better estimates for future delivery cycles. Without understanding how long it took to "invent the wheel" the first time, it was hard for project managers to know how long it would take the next time they needed to build another wheel. At the tactical level project managers now have a lot more information about how long it takes to accomplish the work.

Along the same lines, the department now has a project manager knowledgebase that captures risks from the risk logs, issues, and lessons learned in a central repository as this data and the schedules are all stored on Project Server. Project managers can query reports to research projects that are comparable in size or complexity to get a better sense of what to expect. They can actually recycle a lot of the planning, which is an activity they weren't capable of before.

The timesheet system is also being used by contractors, which provides a consistent way of viewing the hours spent by contractors against the actual activities they work on. This has a practical benefit. Previously, contractors would bill the department once a month. Now business managers receive a weekly report with a summary of the contractors' Project Server timesheet entries, so there's no shock when the invoice arrives. Business managers are able to keep an eye on the burndown rate for contracts and intervene during the month as necessary before the phasings can wreak havoc on the project.

Finally, although the timesheet process was a huge culture shock for the organization, having the information about how people were spending their time consolidated into a single repository turned out also to be the biggest win. Now the department can report back to those external agencies on what they're getting for their investment. That was something it couldn't provide previously.

Capturing key data has really become the main catalyst to change the way the department estimates how many resources it has available, plans its portfolio, and delivers its work.

And that elder statesman who told me at the beginning of the project that we had nothing that interested him? About a month ago he called to thank us for an enhancement to the timesheeting functionality that we had just rolled out. I took that as my clue that the project culture at this government agency has really started turning around; the journey has been worth every step.

For further information on this article and Pcubed please contact info@pcubed.com.