Archive for August, 2008

In your project, allocate time (and budget!) for research. I used to think that all activities should contribute directly and specifically to the end goal. I now tend more towards the view that you should plan for research. Of course the research should be targeted, but usually a project has a few subjects that will cause you and your team a headache. And generally you can name these areas in advance! Specific problems, let alone solutions, are unclear at the outset. In order to avoid problems down the line it is wise to start your project with research, proofs of concept, name it what you will, to clarify major stumbling blocks.

The most inspiring example of this approach I have been privy to, has been the implementation of Oracle Spatial at a Dutch government agency. A few years back they wanted to consolidate all geographical data from a dozen regional databases to one Oracle Spatial database, covering the Netherlands. This database was needed to allow the introduction of online services to the public. The database had to be completely refreshed every 24 hours, after which the new database would be put online. The most important questions put to this research project were: is it at all possible to load and index all data within 24 hours and what are the response times of typical queries on the consolidated database.

I had the honour to be responsible for shaping this research project into a fixed price project, with a budget that would have been respectable for any “normal” project. In any normal sense though, the project would have failed. It was impossible to achieve the project goals with the then current Oracle release. Of course the next release, due for shipping six months later, made it possible. For any regular project this would have spelled failure. For a research project of this kind: no worries! We simply put the project on hold for six months and implemented our architectural choices on the new version.

The resulting database has been the crucial and stable foundation of the information flows to all clients and continues to do so. An excellent approach.

A few weeks ago I received a Request for Information for a substantial project. There was one question that struck me: “Describe on which moments your organization communicates with the client organisation.” My first reaction was: when don’t we!

To ensure that you deliver what your client expects, communication is an essential! So, describing when you communicate is easy: whenever it is needed . You need to communicate when:
- You have a question you can’t answer.
- You make an assumption.
- You acquire a new insight.
- You got a nagging feeling that something is not right.
- …

Communication is not just meant to transfer information. Communication helps foster understanding, commitment and trust.

This all is of course easier said than done. You can increase the chance of effective communication by having a Project Kick-Off with all stakeholders (yes, that’s right, also including the Business Sponsor who does not have the time). Make sure you have regular personal contact on all levels (Director, Manager, Workforce) both formal and informal. And last but not least: give and ask for regular feedback. You never know what you might learn!

“To follow, without halt, one aim: There’s the secret of success.” (Anna Pavlova, a famous ballerina). To repeat the quote from my last blog.
The goal must be worth it, of course. What are the benefits, what are the costs. Right…the Business Case. For this you should not hesitate to thing big and look far. The worst thing would be if your Business Case is invalidated in a year.

The first project I managed (from bid to production) was a substantial redesign and refactoring of an existing administrative system for a directorate of a ministry. We won the project, because (as I learned later) we had bid substantially lower than our competitor. They had built the initial system. During the project I soon found out why we had bid lower: I had omitted half the essential work from my estimates. In my defence I must say that this essential work was specified nowhere and could only be fathomed if…you had built the original system!

What also became apparant at the start of the project was that new requirements were emerging from National and European legislation. These requirements were at odds with the system structure: it would be cheaper to do a complete redesign and build a new system from scratch. The client did not want to hear this advice: he had just started this project, with the current business case and these new requirements were going to be the next project.

During the project I reminded the client twice of the folly of their ways: the timelines lenghtened (as usually happens in projects) and the new requirements got more and more urgent. Eventually the client listened. When the refactoring was complete and the six external contractors were ready to start the acceptance test they killed the project. A very late and very courageous decision. We got the contract for the new project by the way. The new system still functions smoothly and on the whole it was indeed a lot cheaper!