.png)
Delivering actual outcomes and benefits instead of just outputs for a government agency.
The scenario: As the Project Manager, you and team complete a project to implement a new application with the goal to improve business data management. You conducted a comprehensive requirements gathering, you had the right level of project planning and control, and had good representation and collaboration with the project steering committee, particularly the members representing the interests of the user community. On completion, the portfolio governance group is satisfied and closes the project. Yet, almost right away, the benefits reviews show that business process improvements have not happened to the desired effect. Here is what is happening:
Despite a publicised roll-out, user guides, and training, the system is not being used as expected or used inconsistently
Users still using spreadsheets not the new application
The original data management problems continue and actually start to get worse:
Reports are still full of errors and data clean up is taking longer than ever;
Reported data, even when error free, does not accurately represent reality;
Decision-making becomes flawed and not driven by the right data;
Employees know the data is incorrect and actively promote their views;
The official new corporate information system now holds flawed data;
Warehouse data is incomplete.
So the project benefits are not realised and strategic objectives not achieved, now compounded with new operational inefficiencies. There are many views on how to improve through implementing Agile, or better stakeholder and communications management, and better process mapping and requirements gathering. All of these may be true, but let’s explore ideas and not advocate a specific solution. We need to think about what works best in this specific environment.
So where did things go wrong? One place to focus might be the user-manager communication pattern and relationship. For argument sake, the user is in an office and field and directly inputs and reports data. Managers are office-bound, maybe mid or upper level, and use data. In project management, there is always (or should be) an emphasis placed on the customer or user. What does this mean though in a government enterprise setting, with many levels of employees and directors, maybe in a dispersed, virtual environment?
In terms of project processes, maybe requirements weren’t gathered right, the product was poorly tested or piloted, or generally the input was not gathered comprehensively. Through the lens of this user-manager relationship, we should ask:
Has the manager conveyed the proposed benefits well to sufficiently motivate users to change?
Are managers demonstrating enthusiasm about the new system?
Has the user been informed enough to understand and appreciate the new system?
Have users been convinced, or shown effectively, that the new system will help them better than the old one does (at least in the long run)?
On a program (day to day, cyclical tasks) or strategic level, there are other issues related to organizational psychology to consider:
Are users generally skeptical about a new, centralized or top-down system, even before the project began?
Is there a lack of trust that managers are not connected to daily issues, just order decrees, or don’t understand the workflow of using technology?
Is there insufficient risk appetite of users who already may feel overburdened with regular tasks and new things to learn?
Findings from one US government agency (I used to work for) showed that poor communication at and from the top can lead to poor feedback mechanisms for end user concerns, siloed technologies, and failure to strategically align business requirements with core information needs. This led to data that can’t be aggregated or integrated efficiently, weak data stewardship, limited awareness by leadership of opportunities, and poor product design. In essence, enterprise solutions are not truly enterprise.
What does poor communication look like from these findings? It can mean a few things:
Lack of leadership, comprehensive direction, inadequate communication on technology and program issues, guidance that did not offer comprehensive, complete, balanced, and/or well-planned solutions, and unjustified requirements.
Not adjusting changing and declining budgets as an impact on business process and what it meant for new technology.
Too much push of technology because of what it promises, and not enough effort to ensure benefits by building adequate workflows, protocols, standards and governance to go along with it that would truly help recognize business process improvement.
Competing and unshared values and understanding between offices about information management solutions. This leads to duplicative effort to address similar information requirements.
In short, there may not necessarily be fault in the project, but fault of acute or chronic communication or relationship problems between managers to software users. If managers are failing to build trust and allay skepticism in strategy and benefits, then they will have a hard time selling a new product as well.
This is where the product champion comes in. It may be a mid or high level program manager who represents the business, has known business knowledge and some tech savvy, who has or can build trust and respect with the software users. They should also ultimately have interest in the new software. It should not be underestimated when trying to effectively implement change and it can save a lot of headache during transition to new systems.
Depending on the scope of the project, if it is multi-program focused, agency/office wide, you may want a team of champions, like ‘the usual suspects’, who form an ‘oversight team’ for the project. Their charge will be to keep the project strategically aligned with business needs and priorities, contribute governance, know daily workflows, and anticipate end users issues well. Having a team also may show collaboration and coordination, prevent stove-piping, and demonstrate that the software project is not an IT, CIO, or PMO initiative. If they can do this, then they can demonstrate good leadership with their programs.
The Project Manager needs to have a strong relationship with the champion or champions. The PM should be expected to solve all problems, so with good rapport, the PM can work, from initiation with the champions to develop more realistic business case arguments and benefits, and design more effective monitoring strategies. Upon project roll-out, the champions now must own and deal with long term use issues, so they better be involved continually.
Furthermore, an oversight team of champions can help the project manager smooth the melding of and transition from project process to business as usual program work flows. Champions can help keep project in check and balance with daily, BAU work of program, and filter messaging so as to not overburden themselves or end users with project requests. As the project work becomes more intensive and focused, they can, through regular updates and expectations of input, keep it related to the program and not be isolated and miss something important. By keeping project connected to the program, they can help ensure quality and not lose touch with planned benefits.
Some important lessons:
For the PM, maintain connection between project dynamics and the program world to not be disconnected from daily work flow. Keep focused on constraints of cost, time, scope and even product quality, but loses touch with the outcomes and benefits, and work with the Program managers to make the best transition possible.
Pick or nurture champions who can foster trust and good communication and transparency with end users. If a program manager as champion is believable, and shows belief in the product, and a good understanding of how it improves work, then end users will be more willing to change. Make sure they understand the difference between enforcement of change for mandates or compliance reasons and influencing change to realize benefits, desired outcomes, and strategic improvements.
Pay attention to user sentiment as it changes throughout the year. Not only worry about the project timing and time constraint, but know when is the best time of the year to roll out a new product and training. Program managers as champions should help immensely with this.
Realize you can’t fix everything, not everyone will be satisfied. Change in government and government organizations is slower than changes for a project – risk of pace of change? Benefits might be slower to be realized. Understand differences between mandatory change and improvement change. Realize the burdens that end users may have and what it will take to overcome that.
Capacity Building – Initiatives often fail when they lack interest, awareness, and knowledge among employees, especially leadership. Divergent values and perspectives on the scope of core information issues also reduce the capacity for dialog. To overcome this, project planning must build ground level support. The cultural complexities of an agency also mean that clear and effective governance will need to be invested in to ensure benefits.
Respect for Daily Operations – Software does not bring net benefits if they create or are perceived to create extra work for skeptical and already over-burdened employees. It may not be enough to say new processes are better, or that repeatable, standardized, or automated solutions will improve workflows. This is where champions leading pilot efforts may help. Real solutions that employees can point to and say “this makes my job easier and integrates with the best technologies” will be important.
Despite opinions to the contrary, government employees do have a lot to do, and ‘can do’ attitudes compel them at times to take on more than is reasonable sometimes at the risk of leaving things unfinished. Change also takes longer in a culture that follows procedure, has cyclical reporting, and employees who are committed often for the life of their professional career. Champions are well positioned because they understand this aspect of the users, they can work out solutions, and have the credibility and obligation of good leadership to keep the focus on benefits that will enable the project manager to best do their job.