The Customer Dilemma

I often find the most challenging part of an IT project is working with the customer. Now I firmly believe that business should drive the technology and not the other way around. My favorite adage is the example of a car, the developer can tell you the best place to put the ignition and the best design for aerodynamics, but they should never be the driver, or “Never give the nerd the keys”.

The basis for every IT project should be the requirements of the project. These requirements should be developed with great care through a close relationship with the customer. This I am firmly committed to in every IT project that falls under my responsibility. So where is the customer dilemma that I’m talking about?

Well, that is the rub, the project’s foundation is the requirements, however, that is far from the end state. Some customers want to insert themselves into the design and development process. In my experience, allowing the customer this much access during the design and development phases will cause scope creep and most likely delay the project and lead to cost overruns.

Now some would argue that these are acceptable consequences for the benefit of the customer input. I would submit that this same benefit can be achieved through regular project updates and a solid change control process, without the same risk of scope creep, time delays, and budget issues. This will allow the IT shop to control the scope, cost, and schedule. If additional requirements are added through the change control process, they are scoped, budgeted, and scheduled and therefore are not delays.

The key to this process is customer education. Some customers are so used to having the developer at there disposal, with the ability to tap them on the shoulder and suggest a “slight” change in the project. The developer wants to be helpful and quickly implements the change, with little or no documentation. This slight change only took a “couple of days” to put in and the customer is happier. Right? All is well!

The project is scheduled to be complete at the end of the month and at the project status meeting the developer informs the project manager that he is a month behind schedule. Because over the past six months the customer “shoulder tapped” him about once a week. Now we have a gold plated application that is behind schedule and over budget. The same customer who had been doing the shoulder tapping is now upset with the project manager because his project is delayed for a month and is going to cost more money. Whose fault is this situation? The project manager is to blame; they must control the project, which in turn means controlling the customer.

As a customer is educated to the benefits of a solid change control process they will learn to embrace it. They will understand the impact of the change requests and understand the responsibility they have in the project. This will also help the developers focus on the actual work and complete the project on time and within budget.

The educated customer is happy and in full control of the requirements through the change control board, without controlling the IT development work. The end product will meet the needs of the customer and then everyone is happier. (Don’t we all wish it work this way every time?)

All this being said, the customer dilemma is very real; I wish educating customers were as easy as it sounds, but it takes a major paradigm shift. This is especially true in the world of re-organization that is covering the industry currently. It is also important to pick your battles, remember that the war is not won on a single battle, but through very small victories along the way. As you show your customers your can be successful and deliver a product that meets their needs they will be more willing to provide you with the needed support in the change control process.