Home > Business Approach, Clients > Wait, we need to ask the client?

Wait, we need to ask the client?

While traveling recently, a colleague commented that he wished companies “would stop listening to their end users.  If it weren’t for them, we could get these projects off the ground.” 

I had two immediate thoughts, the first – the old pun “business is great except for all the clients”  – and the other – what exactly defines a client?  Is the client the one who pays the tab (aka management) or the ones who consume the result of that project (aka end-users)? 

My thought, in short, is both. 

In the world of software implementation projects, there are equal measures of frustration and pride for a project team.  Yes, end users are demanding and tend to resist change; yes, leadership expects impossible deadlines, and all too often IT considerations are an afterthought.  However, a project managed correctly includes input from all stakeholders, including the end users whose excitement builds ground swell support ultimately leading to a successful implementation.  So, what differentiates success and failure?

In an ideal situation, a rare occurrence, the company’s leadership has done everything they can to insure success:  product evaluation, supplying needed resources & time, knowing the limits of systems & staff, acting as champions, etc.  To find a company who has even two of these items is, at times, fortunate.  That said, this list would be a fantastic start for a project.  Projects are never solely successful when pushed from the top down – it helps, quite a bit mind you, but is not the only reason. 

We have discussed management, in brief, let us now consider the solution’s consumers, i.e. end users. 

Projects impact people, whether that impact is positive or negative depends on your approach.  Your PLAN (yup, you need one) must include a series of questions to ask and things to consider before undertaking any technology initiative, which – once resolved – will make it successful (or at least less likely to fail.) 

This is obviously not an exhaustive list but designed to get your group thinking – what have I not included that is vital to your organization?

 

Plan:  First and foremost, do you have a plan?  What is your goal with the new system?  What business problems do you want to solve?  Have you evaluated how your business processes will change or if they need to change?  Where can automation help; where will it hurt?  Is your company, department, etc. self-aware enough to know what type of rollout is best?  Who is on the team?  What skills are needed?  What resources are needed?  Has IT been involved from the product / vendor selection stage, or ideally before? 

Management Support:  Does the project have management support, i.e., when the requirements gathering phase is over, will the company’s sponsor step in to enforce a “code lock” to stop endless tweaks?  My colleague had a point, there is a time for generating a list of all possible needs and then one must stop making changes to allow the developers and others to do their magic within that framework.  Nothing derails a project more than scope creep & change after change.  Put the time into a solid design and then implement!  Keep in mind that by following this method, you will have multiple phases to your project’s rollout; however, smaller more frequent changes may result in greater gains.

Data:  What will be (if any) the by-product of this initiative? For example, using a CRM should produce a more robust pipeline of qualified sales leads, those leads may then become customers with their own unique needs, etc.  The way data is produced, managed, and shared among systems can have an enormous impact on your users’ daily life. 

Focus Group:  Would forming a cross functional steering committee benefit this project?  Including stakeholders from all functional areas and levels of the company opens conversations that may otherwise be ignored.  One warning: these groups are historically cantankerous; however, that is exactly what you want – for real dialog to occur!  Remember the business axiom: forming, storming, norm-ing, and performing!

End Users:  Who are the consumers of the new technology?  If their needs, concerns, and ideas have not been given a voice, then your users will not use your solution.  Simple.  The users know what they need, where the pain points are, and whether a proposed solution will be easy to use.  By considering the end-user experience, you will greatly increase their acceptance of the change.

To increase your project’s success, think about all stakeholders – management, IT, end users, and all others who will be directly or indirectly touched by any proposed change.  As a final thought, from Peter Senge, “People don’t resist change. They resist being changed!”

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: