Getting started on a software project

I have a problem with starting software projects. I have been working with software for my whole career, and typically when I start working with a company, I understand the situation and what needs to be done.

While it is obvious to me, it is seldom obvious to my clients and their staff. They called me for help because they were not able to achieve the goals that they set out for themselves. I am ready to get going and can see the steps that need to be taken, but I can't go there.

Over time, I have learned that I can only go as fast as my clients are capable. In the early stages, it seems quite slow and little visible progress is seen. This can be frustrating for managers of projects as they are anxious to get going. However, this is a difficult time for people to go off in a rush. They are working in unfamiliar territory, with changes to their business processes, new technology and tools and typically a new list of issues every day. This is not normal operations.

Many consultants will offer a "solution" to this problem. They will bring in a group of outsiders who will make the project happen. There is a flurry of activity and everybody is happy. Then the project grinds to a halt. Often this is because roadblock and roadblock has been put in the way. This is usually after a lot of money and time has been spent. The reality hits that the staff has to know what is going on. It can't work without them.

While the early stages of a project can be frustrating for those that know what needs to happpen next, it is a time of learning, and sometimes learning can be slow. people learn what they need to know. Once learning has started and everybody understands where things are going, they start to look for opportunities to use the software and they understand how it can help them.

This occurred in a recent project that I worked on with a client. The first month was frustratingly slow. We focused on the business process and looked for ways that the software could help improve the process. We uncovered many process issues that would prevent successful implementation. In the second month, things were still slow. Volume of work prevented catching up with the backlog, but now we were no longer building a backlog. We were keeping up with day to day requirements. More process problems were identified and resolved. By the end of the third month, the staff had taken ownership of the software and could see how it was helping them. The backlog was eliminated and the software was functioning as desired.

Although progress was slow in the early stages and required ongoing support and coaching, the learning process was happening. The slow start was worth it.

In starting any new project, leave time for learning. Start slow. It will pay for itself later on. I have seen too many failures where companies bring in a ast of thousands to make early progress. The only thing that they succeed in doing is increasing the costs.