By now, it must be clear to most people in the software industry that software projects seldomly go as planned.
There is a lot of debate in Denmark about
large govermental IT projects that fail. It would have surprised me more if they didn't fail. They are large project with a vast number of details that must all be fullfilled for the projects to succeed. That's just not a realistic scenario.
An IT software project is about inovation and not about building something already known. If you encounter a bump on the way on the road, you shouldn't have to force your way through it if there is a more sensible way around that was not part of the project to begin with. There's bound to be some experimentation going on during any project and you must be able to change the requirements along the way as the parties involved get smarter and discover things about the domain at hand.
These days, the role of the project manager isn't to keep the project on track, but find a way when changes to the requirement ocur (not if, when).
If an IT software project is to support change, it's needless to say that it requires a lot of involvement from the client (the buyer of the project). You can't order some software that takes 3 years to build and expect it to be like you imagined it to be if it is build solely based on a document you wrote to begin with. If you want to benefit from a project you have to get your fingers dirty yourself.
No comments:
Post a Comment