Successful Projects do not come by chance

Originally posted on June 27 2012

chances.jpg

There are several aspects to be considered, while initiating the long process that leads to a successful project. None of them is second to the reason why the project has been set up in the first place.

The project exists because the customer has a pain or experiences bad performances. Thus, the project must fix the pain or improve performances.

The more directly we point to the desired outcome, the better the project will be received, the more the customer will revert to us again for a new project.

This, of course, must not be done at expenses of long term viability. A project that set up a complex structure (db, code, reports, dashboards, whatever) and can’t scale, it is a half failure. Actually, the good project is the project which sparks many other good projects. Do not worry of doing too much, usually there’s a long way before maxing out a customer, and a good reputation is one of the sweetest fruits of a well done project.

Sometimes a project fixes an issue but does not meet the customer expectations. Those who design systems should always try to walk the extra mile to understand how, in customers’ mind, the project is supposed to fix the issue or improve the performance. For example, a new and innovative cost accounting project may well produce a detailed P&L, but with poor what-if capabilities (calculations too long or parameters too complex to be changed etc.). Maybe those capabilities where not expressed, but it’s up to us understanding the client’s requirements even beyond their knowledge. The ability to foresee what the customer is going to ask you next, comes from experience and it is essential.

When this, hard but rewarding job is done correctly, people shine when talking about you and your work.

So far we have talked about successful project form the customer perspective, but we do not do projects for philanthropy. A successful project, from the consultant’s perspective is, above all, economically sustainable. The contract architecture should be carefully crafted to preserve margins. Risks must be carefully evaluated, scope creep, to a certain extent, should be given for granted.

After all it is not an easy job, but it’s fun anyway.