Keys to Project Success - Part 10

This post is a continuation of  Keys to Project Success - Part 9

Keep Stakeholders Engaged

Years ago, very shortly after I’d taken over management of a new team, there was to be a demonstration of a new set of features that my team had developed.  The demonstration was for the heads of the business areas that would be using those new features.  The software was to be imminently pushed to production, and this was the final step.  I was just about to round the corner into the demonstration room when I heard one of those VPs say, “Well, what did you do that for?  We didn’t ask for that!  That’s not going to work!”

Ouch!  Having spent a substantial amount of my career as a software developer and managing teams of software developers, I wasn’t just disappointed by what I’d just heard – I was puzzled too.  What went wrong?

After that demo ended, I sat down with the manager in charge, and went through everything that had happened from day zero of the initiative to that demo, and a couple of things became very clear.  One, we had a pretty awkward process end-to-end, and not in line with best practices.  And two, as part of that awkward process, we never spoke to the ‘client’ – the group of people that would actually use what we were creating.  We just took what another group had prepared (without that group really understanding what would come next), scratched our heads when we couldn’t make head nor tail of it, made some assumptions, and carried on, blissfully writing software without ever checking in with the business area until the very end.  Not exactly a recipe for success.

If there’s one thing I’ve learned in my career, it is to keep my stakeholders meaningfully and frequently engaged in my project.  If I didn’t, any and all of the following could (and usually at least a few would) happen:

  1. I deliver the wrong ‘solution’, wasting time and money, and potentially causing the business to miss opportunities.
  2. While what I deliver might technically solve the problem, it won’t do it in a way that is convenient, easy, or obvious for my business partners.
  3. There will be ambivalence to resistance to what has been built, as people are generally not too keen on things they feel have been forced upon them.
  4. Whole areas of functionality will be missed, severely compromising the usefulness of what has been built.
  5. If the solution was to be part of a larger system, if will have negative side-effects on another part of the system.
  6. I’ll have massive rework to do to ‘fix it’ so it works the way the business area needs it to work.  This work will be rushed, and will likely introduce further problems.
  7. My business partners will start to trust that whatever I build will always be wrong the first time, and will eventually look for a supplier of solutions they can trust.

You get the idea.

What does that meaningful, frequent engagement of my stakeholders get me?

  1. Walkthroughs and approvals of requirements, design documents, prototypes, project plans, test plans, and other key artifacts all along the way means I get to make little course-corrections throughout the project.  Sometimes they’re minor, easily absorbed into my project’s contingency.  Sometimes they’re material, resulting in the project change management plan being invoked.  But either way, with those course corrections, we’re much more likely to get to where we need to be, with my business partner in the seat beside me helping navigate as opposed to them standing at the starting line, pointing, and saying, “um, ok… go there,” squinting off into the distance hoping they’ve picked the right spot at which to point.
  2. I get to leverage the people who will actually have to use what I’m building to help design the interface, workflows, and other user-experience elements of the solution.  That means that (a) it most likely will work the way they need it to work, (b) as part of the test team, they’ll be able to verify it got built the way they designed it, (c) they’ll have a sense of ownership and pride around what they too have been creating as part of the project team, which means (d) they will be my evangelists.  I won’t have to sell it to their business team, or convince them that it really will address the business challenge.  They’ll do that, knowing it will work the way they want it to work.
  3. We (the technical team and the business team) will consistently get to the end of projects with solutions that work, work well, and with everyone happy.

That’s a pretty good deal!

So how do I keep my stakeholders engaged throughout?  Well, there are a few key must-do things:

  1. Very early in the initiative, get the driving business area to assign a ‘business project lead’ from that business team to be the overall project manager’s business counterpart.  This is not a business analyst role, and it’s not a technical role.  The person doesn’t necessarily have to have any project management experience (although that doesn’t hurt), as the overall project manager will be taking care of those aspects.  But this person will be the key provider (or conduit where they may not know themselves) of business knowledge, arranger of business resources for working sessions, reviews, testing, etc., and the person from the business who will constantly watch to make sure the project is going in the right direction.
  2. With that business project lead, again early in the project, identify the stakeholder groups, and approach them.  Make sure you are clear as to what their stake is in the project, and determine the level of involvement they should have.  Do this with them collaboratively.
  3. Plan the project with tasks that are specifically there to ensure that meaningful, frequent engagement.  Schedule requirements development and design working sessions that have the effected stakeholders present.  Be sure to leverage collaborative techniques.  Other key things that should be there are walk-throughs and approvals of requirements, designs, prototypes, test cases, and any other work products that will have an impact on various stakeholders.  Do this planning with the business project lead, to ensure that person is on-side with the level of collaboration. 
  4. Get the commitment from the various stakeholder groups that they will have the right resources available at the times needed.  Take names.  If you cannot get that commitment, escalate it as a risk to your project sponsor / champion, and get them to intervene.
  5. Follow your plan and make sure those joint sessions are meaningful, where there is true input from your stakeholder groups.
  6. Check-in at all levels with open, frank communication.  As the VP in charge of multiple projects and releases, I would frequently check in with my business area counterparts as to what their perceptions were of how various initiatives were progressing.  I’d make sure that the project managers knew what I found out, and if we were out of synch, we’d find out why, and fix whatever the problem was.  Similarly, the business project lead needs to check in with the rest of the business resources (including those from other stakeholder areas), the overall project manager with all the technical resources, and reconcile the various perspectives on how the project is going.
  7. Keep all formal communication (status reports, project status meetings, etc.) as succinctly meaningful as possible.  I’ve always tried to ensure full and rigorous reporting with as little ‘paper’ (physical or electronic) as possible.  I’ve seen over my career methodologies that are truly onerous in the amount of material that is prescribed when a far simpler and to-the-point report would serve equally well.  And trust me, your business partners will likely not read that hefty version, and resent you for piling more on them, which does nothing for engagement.

In some business’ cultures, getting the business to commit to this degree of engagement may be a challenge – one I have faced myself.  What I have found works (and it still often takes perseverance) is to gather some metrics on the results of past lack of engagement – delays, increased cost, missed opportunities, lost revenue, frustrations, etc. – from that business itself, and then echo those metrics back to people who are resisting.  They will likely remember those unpleasant instances, and that recollection opens the door to being able to say, “I have an idea on how we might make it better.” 

Once you start the transformation, make sure your project managers gather metrics on the various bullets they were able to dodge as a result of that better engagement.  It is powerful affirmation to be able to say at the end of the project, “we avoided $1 million in cost because we were able to make these course adjustments along the way,” or, “if we all hadn’t been in that working session where you pointed out why our idea wouldn’t work, and then we designed a good solution, we’d have had to rework the whole thing, and been a month late.”  And in one case from my own experience, “Do you remember a couple of years ago when we used to put stuff in production and there were so many bugs?  Did you notice with the last promotion there weren’t any?”  That felt good.