 |  |  |
| Main | |
The Large Software Contract Problem
Large government software contracts are in some respects like large highway interchange construction projects. A lot of money is allocated, there is a bidding process, and one or a team of contractors wins the contract which is scheduled to take several years. Unfortunately, that is where the similarities end.
A large highway interchange construction project is based on a much more mature industry with a much more concrete goal: roads and overpasses that meet well-established specifications for roads and overpasses and traffic that flows. To imagine what a large government software contract is, think of what the same highway interchange project would be like if they did not know the terrain, only that it was possibly a mixture of land, sea and cliffs. Add to that, there are no reliable maps of the roads leading into the construction zone, just numerous rumours of traffic jams. Add to that, the exact types of roads and overpasses required may or may not have ever been built before.
It is understandable that when the lucky team is awarded the large software contract an initial period is allotted for assessing the situation. A preliminary assessment was already done to write the proposal, but that involved a lot of guesswork. Now it is time to get a real handle on the parameters of the project. Or is it?
Actually, the reality is that when a large contract is won, that is when staffing begins! Some of those who helped write the proposal may take the lead in the new project, or not! Staffing the management of the project will be a political thing of course because a lot of money and prestige is at stake. Staffing the rank and file is prone to a mad desperate scramble for bodies, where a lot of the best people are jealously guarded by their management elsewhere.
Needless to say, all of the new people on the new project may not share the same vision as those who wrote the proposal. Undoubtedly there are some people who have been given big responsibilities that they may not know how to handle. So not only are they trying to assess to parameters of the project, they are sorting out their ideas for how to organize their efforts. This stage of the project comes with huge risks; in fact, if you could properly gage the success of this stage, you would probably know the outcome of the whole project.
Somewhere in this whole process is the customer, collectively hoping with some nervousness that this huge expenditure is going to begin positively impacting work life sometime soon.
Having won a large contract, the team management might have a tendency towards feeling a little bit self-important. Without going into all of my ideas about large projects, I'll just leave you with one small suggestion: the customer is the key to the success. I know it sounds obvious, but this is a "service" industry and a servant's attitude, as in many aspects of life, yields great things.
Getting to know the customer, not only hobnobbing with senior representatives of the customer but reaching out to those regular customers who operate the software, helps everyone involved during design and planning an effective solution. Also, immediate enhancements to the user experience of existing software goes a long way in getting to understand the customer requirements, as well as engendering good will and a good relationship.
Keith Casey describes a simple yet effective improvement that really made an immediate difference for his customers in AJAX and making Customers Feel Good. I'll have a lot more to say on large software contracts in upcoming posts.
| Main | |
