Friday, May 8, 2009

Same Mistakes, Different Client

One of the phrases I am becoming more and more familiar with is “You can lead a horse to water… but you can’t make it drink”. This is probably one of the truest statements that can be made about corporate America. I have now worked on large expensive technology projects for five very large and well know companies and they all seem to make the same mistakes. Each corporation just seems to make these mistakes with different levels of severity. What is even more amazing is that when I did a little consulting college for some small companies I ran into similar problems.

This is actually the second time I have tried to write this post. The first time I stopped after writing what would have been a couple page introduction to an academic paper or the first chapter of a project management book. Neither of which I am inclined to actually write at this moment. The reason for this is I started getting into some details that would bore most people. So instead I am going to move up to the 50,000 foot level an give a high overview.

The main mistakes most corporations seem to make on large technology problems are:
1.) Under estimating the scope of what is really needed by the business – executives always want out of the box solutions while the resources that are down in the weeds want something that more closely follows their business model. The end result major scope crepe on almost every project I have been on.
2.) Poor tool selection – many companies simply pick the wrong tool, whether they make their decision on price, existing relationship with a vendor, kick backs, who knows picking the wrong tool adds significant development time. More time should be spent up front of vendor selection.
3.) Under Staffing. - When we as a consulting firm bid a project we always go in and say we need to staff the project 60-70% with client resources to keep the cost down and have enough decision makers to actually get things done. What happens most of the time is we get 30-40% and have to staff more consultants. The problem is while consultants may know a client’s industry and the technology involved they don’t know the clients business as well as client resources and the end decisions always have to be made by the client. So the less client resources the longer it takes to get work accomplished. The right mix is critical but always seems to be off do to the lack of client resources committed to a project.
4.) Overlapping waves – When rolling out a multi-site project you either do all the sites at once, or get a single stable solution up and running and then start more sites. You should not start site 2 in the middle of working on site one, and you certainly should not schedule several over lapping roll outs. It causes confusion, overloads shared resources (making mistake 3 worse), and almost always ends up with a worse overall design and solution.
5.) Consider the largest user base in the initial design – It is a fine idea to start with a small pilot before deploying to larger sites. But the design should be around the larger sites. Otherwise you build and stabilize a solution that does not fit your business and you need to start design over in the subsequent roll outs. If the largest user group is focused on from the beginning subsequent waves will need fewer changes and become simple. Lowering overall costs and possibly speeding up time lines. The opposite seems to happen however.
6.) Have strong controls – Before the project even starts project phases, milestones, time lines, deliverables, and process should be set. Also a single repository for data with version control should be set up. Nothing leads to more issues than having a lot of people following different processes, creating the wrong documents, working to the wrong dates, and creating multi versions of deliverables that don’t meet any of the requirements.
7.) Lack of executive commitment – This the most egregious error that can be made. Executive management needs to show up and let the legacy/IT/Systems people know that they want the new system and are willing to fire or remove people that are not committed. A lot of projects get derailed because executives fund a project and then forget about it. Many companies have an institutional aversion to change and people will under support and actively try to disrupt projects. They will also try to make the new system work like existing systems negating many of the benefits of doing a project.

I think the first 6 mistakes are common because companies want to get the most bang for their buck so they try to go as cheap as possible as fast as possible; when a longer time line with a more expensive initial price tag has more chance of success. In the end when the project gets in trouble and mistakes have to be corrected a cheaper solution can cost twice as much as the alternative. Corporations seem very bad at looking at things holistically and finding out what the total cost of ownership actually is on competing projects.

The last mistake just comes from many executives lack of experience dealing with such large solutions and there propensity to believe their company won’t make the mistakes other companies do. Because of this and their busy schedules they simply don’t make enough time to deal with projects. On the flip side it also seems that companies and many mid level executive simply don’t want to deal with problems when it could rock the moral boat. Removing people that cannot perform or are unwilling to make things happen is not a fun thing to do but sometimes it needs to be done and isn’t.

What is funny is that I have seen these same conditions exist in small business, at universities, in government shops (actually probably the worst offenders), government contractors, as well as the large fortune 500 companies. It really is amazing that the same themes repeat themselves so often and I have seen my firm give all the advice necessary to avoid these problems and yet time and time again we are ignored, even when they are paying such a premium for the price. Oh well I guess that is why I have a job.

No comments: