Thursday, December 14, 2006

Project Turn-around – Crisis Intervention

Several years ago a client of ours was on a collision course with a brick wall while developing a new product. As usual the project was 6 months behind schedule, the client’s customer was extremely unhappy with no delivery and no one had had confidence that the project would be complete at all.

That is when I was hired. Fortunately I had worked with this client before so I knew who really knew what was going on. I was able to obtain copies of the specifications and project schedules. As expected both were incomplete. The project schedule was based upon delivery dates not the actual level of effort to perform the individual tasks. I asked management what leeway I had to effect changes. Quite a bit, actually, as long as the project was completed “successfully”.

I gathered the development team around and asked why is the project where it is. There were so many reasons but the main thread was that no one knew exactly what was expected of each and none believed or bought into the published schedules. Of course the requirements specification was weak, aren’t they always, but surprisingly the team seemed to have a pretty good idea of what the product was supposed to do. They also wanted to succeed.

Following a review of the documentation, code base and the issues stated by the development team, I was able to formulate an approach not yet a project plan. I recommended to management that all software development stop immediately. That we needed to complete the requirements definition ASAP, get management buy-in and then focus on the architecture. Fortunately the underlying technology was not an issue. Once those two items were taken care of we could produce a new schedule with buy-in from each developer. I was also able to determine if we had the right mix of skill levels. I noticed we needed a senior DB designer and a Software Quality Assurance person to be embedded in the team. Management was agreeable.

Finally the personnel were in place and a new project plan was published. Not exactly the dates management wanted but they were prepared to give us a chance to prove the turnaround. A key component of the new schedule was demonstrable milestones that could be shown to management and to their customer to gauge progress. I believe that was essential in management’s decision to approve the schedule. So how did we do? Well, there were many bumps in the road but the process was transparent so we could address issues early. The product was ready for delivery very close to the schedule’s published delivery date and the end-user was NOT ready. Finally the product was installed and turned over to the end-user.

Then I took a vacation!

Friday, December 8, 2006

You haven’t worked in our Industry

Here is a question I hear when working with new clients in different industries. How can you help us if you don’t know our market? Over the years I have tried to be vertical market agnostic in the pursuit of technology solutions. So when I come across this question I am ready.


My reaction is that domain knowledge does matter however the application of technologies that work to solve similar problems in different industries could be just as helpful. I find that just by mentioning a related problem encountered elsewhere and discussing how we solved it and the technologies used really brings the client on-board fast.


Technologies come and go quickly, much faster than typical product innovations. Companies used to certain communication mechanisms or display devices may not see the exciting changes happening. Certainly not all technologies are applicable in every market however many are and the challenge is to choose carefully.

Monday, December 4, 2006

Is source code control for everyone?

Sometimes I encounter clients who do not have source code control. Actually they say they do because ALL of the source code is on the programmer’s computer. It is all in one place, we can agree on that!

Most developers would agree that when a team of programmers is working on a project you need to have managed source control. But why not even for a single programmer project? It is true you don’t have to worry about merging changes from multiple programmers, but you do need to know exactly what code was included in each release. It is also helpful to be able to roll-back to earlier versions for the solo programmer when looking for the impact of changes that may have introduced bugs.

Today there are many source controls tools to choose from, including open source versions. There really is no software development project too small that would not benefit from source control.