Enablement is more than ‘support’. Support is reactive and somewhat passive; enablement is proactive. You want them to proactively take action to ensure the success of “their” project and its outcomes.
In user-land your project is additional workload to business-as-usual and its demands, as well as any other projects that will impact the same user area. You therefore need to compete for their attention and commitment. Don’t assume that because your project is approved or even deemed ‘critical’ that the user staff and management will make the necessary time for it, let alone actively enable it.
One user manager refused to let his staff attend training because he needed them full time to deliver the business results that would ensure his bonus. Another user manager refused to allocate staff to a project because they were too busy with a boom in business. This latter project’s costs blew out from $30m to $70m and the project failed twice in two years— but still this manager would not budge. (Both failures of the project were put down to ‘poor project management’!)
Firstly, put yourself in your users’ shoes. How busy are they? What impact will your project have on them during its delivery lifecycle? What impact will your project have at implementation? What impact will your project have after implementation? These are three very different questions that will usually have three very different answers. And, if you don’t understand these answers you will not get the business enablement you need.
Let’s take a project with many benefits and a very positive ROI, which impacts some core business processes, has to be rolled out over many sites and will result in less staff. This translates in user terms to high risk (to operations, customer service and my bonus), high disruption (as the implementation is rolled out over a time period) and high stress (as people worry about losing their jobs). In this type of environment, how do you get their commitment and proactive enablement?
The best way is to deliver progressive outcomes and benefits. In many users’ experience projects are coming, coming, coming, promising a lot, coming, and then come and disappoint. So there is a large degree of healthy scepticism about all projects that automatically dampens commitment. If you can make things better now, improve the status quo, show real benefits along the way, “Hey, this is a project that works!” If it works, it is really coming and is worth committing to.
Address the real concerns. How will business-as-usual be preserved during implementation? — Back-filling staff? Contract resources? Reduced expectations (and bonus measures)? How will staff to be ‘saved’ be identified, notified and treated? Will there be outplacement support? Will the process be transparent? Will it be voluntary or compulsory or a bit of both? And so on. The more that is known and understood, the more commitment can be expected.
To some project managers this is all outside their domain. “This is business management stuff.” Not so. You need the business to be getting ready to take on your project’s outcomes. You need the business staff to be willing and able to change. An ‘A1+’ project still depends on the user’s adoption and use for it to be deemed successful in the business’ eyes.
Sit down with your user management and staff and discuss their issues, their concerns, their pressures and what they require to ‘enable’ the project. Discuss with them ways to overcome obstacles and concerns. Talk to your peers for their experience in comparable situations. Try some ideas to see whether they work. Importantly, work together with the users to find solutions. This builds rapport and trust, which leads to enablement. (NB When front line staff are involved in these discussions they will often overrule their managers with solutions and their willingness to ‘go the extra mile’ to make the project succeed. So their involvement is critical.)
But, when you sit down with the users, have a clear idea of what enablement activities you want them to take on. What they need to do beyond the project’s ambit to ensure the project succeeds. This may mean changing leave options this year, retaining staff that were to be let go to provide cover during the implementation phase. And so on. The more you can point them in the right direction, the more able they’ll be at enablement — getting ready and being willing and able to adopt your project’s outcomes.
If your users and their managers are obstructive you need to pass the problem on to your governance team. If correctly constructed, your governance team should comprise of managers and executives who control the user areas impacted. They have a choice; to require enablement or forego the business benefits they were expecting. Their decision may disappoint you, but they will have to live with it, not you.
You can lead a user to water, but …!
Further support and useful tools to enhance the success of project managers are available from valuedeliverymanagement.com .I B
For the previous article in this the series visit "What Should You Expect From Your Stakeholders? Expectations".
For the first article in this the series visit "What Should You Expect From Your Project Sponsor? Ownership ".
Jed Simms is CIO magazine's weekly project management columnist. Simms, founder of projects and benefits delivery research firm Capability Management, is also the developer of specialised project management and project governance Web site www.project-sponsor.com
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.