January 13 by Eric Thiem
The three tenets of any technology implementation are often recognized as being ‘People’, Process and Technology. Like a three-legged stool, you leave one leg out or come up short on one leg and the whole thing falls down. If it does happen to stand, it becomes very awkward to use. The ‘leg’ that this article will focus on is ‘People’ and the role they can play in terms of participation in the consultant-led implementation of a technology tool or product. The individuals who will ultimately be end-users of a new tool must have channels made available to them, to participate on a project team. They should be providing feedback and ultimately helping you as the consultant understand what’s “really going on” in their roles, on their teams and in the organization. If consultants and partners only listen to the executives and management personnel who sponsor the project, the truly empowering outcomes of an implementation will very likely be left behind.
Who are the right ‘People’?
In terms of Enterprise Change Management and the three-legged stool concept referenced above, we are talking about the ‘people’ who will ultimately be end-users of the product or tool that is being developed. Customer Service Agents, Sales Reps, Field Service Agents, Billing Reps, Finance, Operations… the list goes on. By job title alone, the ‘People’ who are added to a project team may not be leaders – but you will want to identify the folks who stand out in their respective part of the world. The traditional IT monolith has left these folks out of the loop throughout the software development lifecycle on projects of bygone years. They had zero input on the project whose outcome would become their new work domain. Meanwhile executives and management personnel – who chose a tool or technology based on “cost savings,” “increased efficiency” and “heightened employee engagement” – might find their heads spinning when such promises fail to come to fruition after feeding the project team with their own vision for a better future, their requirements.
What do we do with these ‘People’?
The ultimate end-users must – not should – be utilized within every phase and deliverable of the project for their subject matter expertise. The folks you want to bring in may or may not have experience working in Waterfall or Agile, they could have minimal or expert level understanding of the software development lifecycle; and they may or may not be able to write code. The important point is that they have what the executives and management don’t: they know what it takes to get their jobs done at a very granular level. They understand what really is efficient or not, they have a different perspective of where money is being wasted and they tend to know where the roots of disengagement begin to create attrition.
Elicit this information from them, consider their perspective and utilize it as heavily as you can while you create and finalize those requirements! Show them demonstrations and mockups throughout design and development to ensure what you heard and utilized in the development of your requirements is what the ‘People’ had in mind. Engaging end users and SME’s is your key to a successful adoption. Have them create test scripts and run their own User Acceptance Testing. Have them review and provide feedback on the training plan so that they can eventually train the folks who weren’t lucky enough to be on the project team. And whatever you do, take their feedback seriously throughout every phase of the project and implement it if possible (if not possible, add it to the Change Request Backlog and make sure the requestor knows where to track it.) Remember that their day-jobs will still need to be done – and depending on the amount of involvement individuals will have, their positions may need to be backfilled.
How does their participation turn into engagement?
By actively engaging end-users on a project rather than just handing a new system over to them, the organization transforms or shifts in the same direction, equating in gained efficiencies. It is rare that they would be spending 100% of their time on the project; and for that reason the engagement benefits are not limited to the folks on the project team. When they return to the ‘homestead’ to do their day jobs, they will certainly be telling others on their teams about the amazing new tool that is being created. This tends to elicit additional feedback from peers, that the folks on the project team can bring back to the project with them. So while you are only involving a few from each team, you’re indirectly involving everyone – which provides the benefits of wider buy-in and ultimately holistic engagement.
Why is this important?
Earlier in this article we mentioned the universal, all-important goals of technology project implementation – the shiny objects that get executives to sign off on software and consulting deals in the first place: increases in efficiency, cost savings and employee engagement. By bringing in “the feet on the ground” for frequent and substantial feedback throughout every phase of a project, those goals become much more achievable. In another era the saying was, “if you want to know what’s really going on in an organization, brown-bag your lunch one day and sit on the loading dock to eat and chat with one of the workers.” While the way we work may have changed, the transition from a manufacturing economy to a service/experience economy won’t disrupt the fact that the ‘doers’ will always know more, at a more granular level about the ills that plague a workplace – those that technology tools are intended to cure – than do the executives and managers who choose to fund a given project.