Archive

Archive for the ‘Business Approach’ Category

Steering Committee Poll

Advertisements

Common sense?

I sent a message to someone today using Gmail and received the following automated response:

“Note: This Return Receipt only acknowledges that the message was displayed on the recipient’s computer. There is no guarantee that the recipient has read or understood the message contents.”

Does Google need to add such a disclaimer?  Have we become so accustomed to automated tools that common sense is no longer relevant?  If that is the case and we take technology for granted in our daily lives, why don’t we put as much faith in our business solutions?

Have you ever said “yes, I know you see it in the XYZ system, but that isn’t really true and accurate because …”?  There are lots of reasons why this is the case, oftentimes it is simply because the accounting and project management systems, for example, don’t share information (i.e. lack of system integration).  When this occurs, it also generally means that an individual must go into both systems to make sure that there is a manual reconciliation. 

That type of process works if your organization is very small or has few transactions; what happens when you have hundreds or thousands of transactions to account for?  Data entry errors are frequently introduced into the process at this point.  If data is manually entered or reconciled, how quickly is the latest financial information available?  This is a case where automation, implemented correctly, would greatly improve your employee’s confidence in the data and your systems. 

Note that I said when implemented correctly – when rolling out a system integration, it is vital to link the correct data tables and fields, otherwise the first time an employee finds a discrepancy, you lose their trust and will have to fight to get it back, if that is even possible.  Sure this is common sense; however, it isn’t standard practice.  Is this because of some diabolical IT plan for your group to fail?  Of course not, in fact, the complete opposite!  That said, integrations are tricky and without support from both the business users and IT, the project is doomed to endless iterations and eroded confidence.

To combat this, a few simple things can help – the two most important? 

  1. Communicate – if folks feel like they know what is going on through regular milestone updates then they will be more likely to trust the decisions, process, and results
  2. Build a relationship with your end-users (aka employees)  – when employees are involved in planning (think: representative sample), they rightly feel as though they had a voice in the changes being made and will have more faith in what is delivered, even if edits are needed along the way

What have you experienced in your organizations?  How have you succeeded; where have projects failed?  Do your users have faith in your technology solutions?

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!”