Working in an airport, systems are everything. They let you use and optimise resources, from energy to stands, from baggage handling systems to closed circuit television, from alarms to air conditioning, from runways to platform stands.
Systems do not last for long. Technology evolves so quickly that what wasn’t possible three years ago, it’s common knowledge now. And when building a new airport almost all systems must be rebuilt following new requirements: more security, more resources and users, new technologies, leaner operation.
And those new systems need to be designed from scratch. What there was before is rarely usable.
That’s when methodologies are essential. I’ve always believed in methodologies in many developments, but when developing information systems they are more than essential.
One of the worst things that you have to avoid is the crazy-coder syndrome, that is the guy that sits in front of the computer and begins coding and application, or, which is the same, the guy that quickly calls a few providers and tries to learn from them. The companies that go directly to execution scare the hell out of me.
gambling with systems
Let’s make that clear, there’s nothing wrong in learning from providers, in fact it’s necessary if you want to have a clear view of what will be in store for your project, what you can achieve and cost and time-frames. The wrongdoing in this case is to approach providers directly, from the first moment.
Why that? Because everybody has his own interest and his own point of view. And while your purpose is to be able to deliver in time, scope, quality and at no extra cost, the companies are there to earn money (yes, a lot of things more: corporate responsibility, serving the customer, establishing long term relationships… I do know that stuff)
First think, then act
Which is my recommended approach? Follow a methodology.
Yes, sounds strange, but that essentially means following some very sensible steps:
- First think of the viability of the project. If there are major changes to be made, the moment is now.
- Review all the contractual requirements, your stakeholders, as a project manager you’re not working for yourself but for your customer (the airport in my case, and the security director in this case). Make the contractor to review all the contractual obligations, sometimes they are not even aware of all of them.
- Then define the needs of the customer, that’s the requirements of the system you are going to build will have to comply with. Have the provider write them down too. Have the customer validate them. Don’t expect the customer to validate everything once all it’s said and done. That wouldn’t be nice or fair.
- Then design the system. Before building anything you have to have it described to detail. Validate with all your technical customers, those that will have to maintain the system after the launch.
- Now, and only now, you can unleash the geeks and begin to build. In that process you’ll have to be aware of the scope creep, and many more things. I’ll talk about this another day 😉
- Then try, try and try. Do not expect to put everything in operation at once and find the flaws at execution. (I won’t let you) At least three testing levels: at your office, in front of me and in front of the final users. Be ready to test everything once, twice or thrice if necessary. Test integration with other systems.
- Last, but not least, transfer to operation. Keep the possibility of a roll-back available, and make everyone know and participate. Think of formation, of support, of replacement parts.
But that wouldn’t work without planning: general plannings, detailed plannings. And plannings must be alive and constantly updated, as well as properly disseminated, along with meeting memos and the documents supporting all the tasks that have been undertaken.
Sounds reasonable? You’d be surprised on how many projects do not follow any of these.