Over 35 years in the infomation techology field have taught me some hard learned lessons about how developers and clients work to either create success or failure. Over the entire period the statistics on project failure have been consistant. Roughly 70% of all projects FAIL! All of the major IT research groups like Gartner have confirmed this time and time again. Lots of books have been written and courses are routinely taught at our finest business schools. In spite of the fact that we know this to be true, our methodologies haven't been successful in changing the results.

 

Included in this huge number of failures are lots of projects that were declared to be successes when the systems were delivered and implemented. How can this be? The landscape is littered with projects that failed, not because they didn't meet the specifications or weren't technically well done but failed because they were never adopted and used. One of the major reasons for this kind of failer is that the champion and owner of the project left the organization and noone filled that void. Projects that aren't owned die on the vine.

 

Another major reason for projects where the systems weren't adopted is a lack of adequate training. Every system/application requires some knowledge to use well. Failing to commit adequate resources to training is the easiest way to guarantee failure. Good training will leverage your investment to assure success.

 

The other thing that causes a great number of project failures is poor or nonexistent project management. The proprietary development process has created an adversarial relationship between most devlopers and their clients. Both are afraid that the other will take advantage of them. Both have good reason to think that way since most organizations have experiencesd failed or problematic projcest. The best cure for this is to understant the necesity of creating a trusting relationship. Developers need the client to provide clear and decicive input when decisions need to be made. Developers need to be able to offer advice and alternatives when they see a problem in the design or other goals of the project. It is not enough to simply "do what the client wants". Sometimes the client wants something that they really shouldn't want, etc.

 

Good planning and project management builds success into the project. Allowing for enough process to allow a developer to know what they need to know to get it right is essential to successful projects. Having appropriate buy-in from the organizations leadership and appropriate access to decision makers during the project are required to keep things on target and on time and within budget.

 

 

There are two fundamentally different approaches to software dn systems design: Open Source and proprietary development. While lots of developers have adopted Open Source softare (OSS) most haven't adopted an open source methodology or adopted a true open source philosophy. Their management practice is still oriented towards locking in customers long term by keep knowledge close. They build systems using open source software but don't manage to empower their clients in the process. Training for users at all levels of the organization empowers the organization and reduces the cost of managing and maintaining systems. One of the things that I do that is quite different is that I work hard to build training and knowledge transfer into my projects. I insist that appropriate staff are identified to learn how to do as much as possible in-house. I'm more that happy to help when help is needed but I would rather you called me because it really was something outside of the everyday operations and maintenance, etc.

 

As the developer, I am part of the project team which includes the appropriate staff, decision makers, and other out-side resources. Working collaboratively and having clear understanding of the roles and responsibilities of all of the team members makes it a lot easier to get things done. Making sure that the value added of any particular element of a project is well understood and prioritization can be established to make sure that the most important elements get the level of attention they deserve and that small issues don't hold the project up.

 

The devil is always in the details! What most organizations call a specification document is usually a combination of some must have features and a long wish list. Items that take up only a few words can actually turn out to be major issues to resolve and drive the cost of the project. Getting the 85% that can be gotten for a price is the goal. There are always trade-offs and choices to make.

 

So, in summry, what's different about what I do is that I bring 35 years of project design and management experience to the process which allows me to accurately analyze a set of requirements so that they can be translated into a successful project plan. I practice good project management to build success into the project. I insist on training and knowledge transfer to guarantee project adoption and use of the system. My development methodology is aligned with the open source philosophy of openness, transparency and participation. I believe in the "learning organization" and help leverage my projects to grow the organization's capacity as part of the project implementation cycle.

 

If this sounds like a better model to you, please get in touch to discuss your project needs.