Give Them What They Want Orginally posted on the BCS Website on 22 Apr 2009
When designing a solution it is all too easy to get carried away with your own enthusiasm and stray off the brief laid down by the project. Although the solution may be sound, by ignoring the requirements put before you, you run the risk of over-spend and over-run on the project, or even worse completely de-railing it.
Let me paint a fictional scenario. An architect was asked to evaluate an organisations current client infrastructure, identify weak areas, and suggest improvements. Seeing a golden opportunity, the architect drew up a set of documents proposing a complete overhaul of the client design, configuration and deployment systems. This proposal was well received, and after a few weeks of further discussions and planning, the green light was lit for the creation of a project to manage and finance this new piece of work.
Feeling happy with himself, the architect started to focus on all the improvements he could implement and drew up a project plan of all the great things that he was about to do. Meanwhile, the business was implementing its standard project startup process, and a proper project manager was assigned to oversee the project. The project manager then went to the business, told them what was proposed, and asked them what they actually felt they needed.
When the project manager then sat down with the architect it was immediately obvious that the list of requirements from the business did not tally with the architect’s grand plan of improvements. This did not deter the architect, he was the expert on these things, and his view was right. He insisted on following his project plan despite the protestations from the project manager and things uncomfortably moved forward. Time passed, and great products were emerging out of the architects tool shed; new client builds, new deployment servers, and web-based configuration tools to name but three. All of which were well received by the pilot users that saw them.
However, none of this matched up with the Business's project plan - they had a whole different view of what should be improved or changed. Time and cost spiralled onward and upwards, and the project quickly became the most expensive project on the book of work for that year.
The business became increasing frustrated that they weren't seeing the changes they'd requested, and the architect became similarly frustrated that the grand vision he had proposed and was developing was now meeting increasing resistance. Tempers flew and arguments flared.
The end result? The business pulled the plug on the project, and the architect was fired. Nothing was really delivered, and the half developed solutions were simply absorbed into the current infrastructure.
The moral of the above story is, no matter how much of an expert you think you are, always give the business what they want. You may not agree with their requirements, and if you can support an argument to challenge them then by all means try to do so, but never forget that engineering should be driven by the business, and not the other way around.
Enter Your Comment
|
|
|