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!

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.

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.

How do you know how much process is “just right”?

I’m sure we’ve all been in organizations where there was either not enough process, making things crazy and chaotic, or too much process, making it so hard to do anything that we spend all our time trying to get around it. Maybe some of us have been lucky enough to have been in situations where the process was “just right”. It’s possible that we have not even noticed this sublime situation, just because it was “just right’, not in the way, not making us crazy.

Certainly it’s a personal thing – a loose light process may feel ad hoc to some and unnecessarily restrictive to others, but is there some objective way to determine the optimal level? I think so.

The key questions are “what are you really trying to achieve?” and “what is the lightest process that will get me there?” No one tries to make things more difficult or slow down their business, but this is often a result of too much process. This is true whether we are talking about software development, or tracking employees’ vacation time.

Questions

One of my business partners is a philosopher. His favorite question is “why?”

I’m an engineer. My favorite question is “how?”

Most of the time, we balance each other beautifully. He keeps us from rushing into things, and I keep us out of “analysis paralysis.” This month, as we’ve started to prepare for our business planning sessions, this fundamental difference in the way we think has become even more apparent.

I was ready to take the general strategy we labored over last year and put together tactics to continue to move it forward. The “how”. He was ready to evaluate growth strategies in general. It only took one painful meeting for us to realize we were not on different pages we were in different books.

Now, I’m a big believer in examination and introspection, but I also believe that at some point you need to pick a direction, decide to believe in it, and go for it! The question is “when?” I don’t know the answer to this. Maybe it’s when you’ve tried everything reasonable tactic and have not had success. Maybe it’s proportional. (I find that Pareto applies to almost everything in life, but we’ll save that for another day). Maybe there is no answer.

What I do know is that every time we experience this conflict between “why” and “how” we get a little better and a little quicker at recognizing it. I’ve also realized just how much I value the tension it creates – holding us back just long enough to re-examine our underlying assumptions, and resulting in even more confidence, anticipation, and passion around the company we’re building.

The Best Consultants (part 1 of 38,329)

What makes a consultant great? It’s a question I’ve thought about every time I’ve hired one, and we ask ourselves frequently at my firm. It’s not just the technical skills, but then that’s obvious.

The best consultants I know make a positive contribution on every engagement, and that contribution is usually not isolated just to the particular task they are assigned to.

I remember very early in my career as I was making the transition from hardware design to software design, I was having a terrible time with some embedded firmware I had written. I’ll spare you all the gory details, but ultimately a consultant was assigned to help me fix it. Well, not only did he show me the error of my ways in my interrupt handling scheme, but he also began to teach me the things they never teach you in school - the subtleties of becoming a good programmer.

This particular person ended up becoming a long-time mentor and friend so I happen to know he’s made that kind of personal (not personnel) contribution again and again. One thing the top consultants have in common is that they are both willing and able to share their gifts, and do so generously.