There are some universal truths in all disciplines - even in the fluid and evolving world of information technology there are principles that do stand the test of time. The sooner one learns them the better because sloppy habits are easy to acquire and very hard to lose. A programmer is well served to learn good, elegant programming style from the get go, testers devise ways to automate as much testing as possible while aiming for maximum coverage, a designer or architect must know to use patterns, build reusable frameworks and components and a project manager must stay on top of metrics earned value or otherwise, convert risk and issue resolution into a lessons learned inventory that can be used on the next project.
No matter what technology platform being employed or business problem being solved, these are things that do not change and make the difference between a failed or successful implementation.
Over the past year, I have had the opportunity to revisit all the lessons from the early days of my career when I was a programmer. Lacking both the temperament and the desire to pull myself out of mediocrity, I found other things to do. However, having worked with people who had both the passion and the ability to be among the best, I learned enough about the discipline to have discernment. What was true ten years ago, is true even today only the mistakes have become a lot more expensive.
I am dealing with a vendor who is trying to integrate between a client's application and a third party product for which they are the preferred service partners. Given their credentials, the price tag is high.Our implementation is no different from many others that they have done before. The roster of clients they have worked with is lengthy and impressive. You would think with all their diverse experience they would have by now built a framework into which a new project could fit in with minimal effort and that they would be able to estimate size and scope of work quite easily. Common sense would dictate that they would want to reach that level of maturity. Not only would their development cycles shrink, they would also be able to bring on more clients.
As is turns out, none of that is true. Instead of being this well-oiled machine that they should have been by now, they scramble to cobble together infrastructure for the new project, without putting much thought into long term maintenance and stability. They force the client to lock down every last requirement at the earliest date so they can scope and schedule the work assuming all is set in stone. Any revision from that point on is a change of scope that only needs to be budgeted separately but will also play havoc with the schedule. Very quickly, the stress levels on both sides mounts to unhealthy levels, the vendor starts missing delivery dates by wide margins and ties to pin the blame on business requirements - one of the most blatantly abused and minimally understood terms in my line of work.
Ten years ago, when there was not nearly the same diversity of offerings in the packaged solution space, the same set of problems could have killed an implementation and it is no different today. It is still just as important for every member of the team to learn to do their respective job the right way. Lessons learned must become part of a team's DNA and not a time to do lunch while reminiscing over the high and low points of the project just "completed". One weak link in a team's chain can be a huge drag force on it but when you have several of these, the chances of success are almost non-existent.
No matter what technology platform being employed or business problem being solved, these are things that do not change and make the difference between a failed or successful implementation.
Over the past year, I have had the opportunity to revisit all the lessons from the early days of my career when I was a programmer. Lacking both the temperament and the desire to pull myself out of mediocrity, I found other things to do. However, having worked with people who had both the passion and the ability to be among the best, I learned enough about the discipline to have discernment. What was true ten years ago, is true even today only the mistakes have become a lot more expensive.
I am dealing with a vendor who is trying to integrate between a client's application and a third party product for which they are the preferred service partners. Given their credentials, the price tag is high.Our implementation is no different from many others that they have done before. The roster of clients they have worked with is lengthy and impressive. You would think with all their diverse experience they would have by now built a framework into which a new project could fit in with minimal effort and that they would be able to estimate size and scope of work quite easily. Common sense would dictate that they would want to reach that level of maturity. Not only would their development cycles shrink, they would also be able to bring on more clients.
As is turns out, none of that is true. Instead of being this well-oiled machine that they should have been by now, they scramble to cobble together infrastructure for the new project, without putting much thought into long term maintenance and stability. They force the client to lock down every last requirement at the earliest date so they can scope and schedule the work assuming all is set in stone. Any revision from that point on is a change of scope that only needs to be budgeted separately but will also play havoc with the schedule. Very quickly, the stress levels on both sides mounts to unhealthy levels, the vendor starts missing delivery dates by wide margins and ties to pin the blame on business requirements - one of the most blatantly abused and minimally understood terms in my line of work.
Ten years ago, when there was not nearly the same diversity of offerings in the packaged solution space, the same set of problems could have killed an implementation and it is no different today. It is still just as important for every member of the team to learn to do their respective job the right way. Lessons learned must become part of a team's DNA and not a time to do lunch while reminiscing over the high and low points of the project just "completed". One weak link in a team's chain can be a huge drag force on it but when you have several of these, the chances of success are almost non-existent.
Comments