There could be a very formalized project methodology for consulting project, a lot of different specifications, a very complex resource planning and controlling processes and so on. And we can do not use such things at all.

I’ll try to compare below order and chaos, “waterfall” and “cowboy consulting” and to show possible halfway – to do projects by a team of self guided consultants.

Cowboys vs. waterfall

Waterfall

Let’s get down to the first option. To make ourselves and our client sure of what consultants do we may use a project methodology where we’ll define using a half of whole the project time for defining project scope, auditing target processes, designing specs and balancing resources and task plan. We’ll provide our client with detailed specification before we start doing any real job making results that our client can use. But with this methodology we’ll be able to produce some standard artifacts even if we’re not sure in qualification of some of our employees. Frequent meetings with our customer, kick off presentations, project status reports and other formalized activity will let us ability to control progress of the project. I’ll call this scheme “a waterfall”.

More about the “waterfall”, it’s the linear sequential model of a project, consisting of several functionally different stages to be performed in one pass, without repetition. For example, first we collect all the requirements of the customer, and only then we proceed to their analysis. Only after completion of analysis of all the claims we will begin to design a solution. With regard to the automation of enterprise management project phases are as follows:

Click the picture to see it full size. More information about waterfall model can be found in Wikipedia.

Cowboy consulting

Consider the second option: sign the contract with the client, in which the specified rate of consultants and technical specialists, and then send experts with order “to make customer good”. How well they do so “good” we control via timesheets signed by the client. Consultants are totally autonomous in terms of making decisions. Let’s call it cowboy consulting. After the start of the project manager’s intervention may be minimal. If cowboy is not able to sign timesheets by the customer than he or she will be removed from the project and transferred to another project or dismissed from the company. With this scheme we pay to the consultants a certain percentage of accepted job man-hours multiplied by hourly rate, so the risk to pay more than earned the company does not exist. There is a risk of losing clients due to the inadequate qualifications of individual consultants.

Who is stronger – an elephant or a whale?

Every document, every decision in the “waterfall” model is a compromise – it must be understood and accepted by the leaders or key personnel of the teams and the customer. In many cases, if the experience of a member of the team differ from that of everyone else, we will not be able to use this unique experience. Also since all the major decisions taken at the beginning of the project, the knowledge acquired during the project we will not always be able to use – the procedure for amending the “project scope agreement” or the “technical design” can be a knotty problem.

Cowboy consulting has no such weakness. The question only is if it’s possible to mount an effective cowboys team.

SCRUM for consulting

In software development management teams of “cowboys” are the number one hit, and, in general, nothing prevents us to apply such a methodology for consulting projects. We can, for example, refer to one of the most popular of the “agile” methodologies of software development management – SCRUM. This is an iterative methodology, which means that the end result customer gets not in the end of the project, but as the few “meals” throughout the project. The second feature is that SCRUM allows better use of knowledge, skills and inclinations of members of the team using the following principle: there is no manager in SCRUM who speaks a particular member of that of what he or she should do. Team members define together steps needed to be executed to fit customer requirements and every team member on the daily meetengs chooses points he or she will make. Reference to a good description of the SCRUM methodology you can find at the bottom of this article.

Let’s define roles:
1. Customer. In our case it could be some group of accountants
2. Contractor. Team consisting of consultants, analytics and programmers
3. SCRUM master. Human interface. The person who ensures interaction between customer and performer and prevents them from intervening each with other. In original it’s written as “SCRUM master is responsible for making sure a SCRUM team lives by the values and practices of SCRUM”.

SCRUM process:
1. Identification of requirements
At the general meeting customer describes their claims point by point, some requirements can be mandatory to perform, others can be optional. Then the customer in some comparative numbers (perhaps as in money) evaluates each item. Contractor assess each item in man-hours. Resulting document is referred to as “Functional Specification”.
2. Process organisation
The scheme may look like this: the whole project is divided into iterations with duration about a month. At the beginning of each iteration (let’s call it the same way as it is called in the scrum – sprint) contractor chooses items to do from functional specification to obtain the best result at the end of the sprint. At the end of iteration contractor hands over work results to customer in a fully working form so the customer can use these results right after the end of sprint. Moreover, we specify that after an end of a sprint customer can change its own requirements or even to shoose to close the project been satisfied be the results of the last sprint.
3. Within each iteration team transforms selected functional requirements to task list and evaluates every task in man-hours. Next, team members choose their own goals for themselves, trying to take in the first place the highest priority, while taking into account the skills, knowledge and preferences of each team member.
4. At the end of each sprint team hands over current result to customer.

Tracking the progress of the project

At any time during the project you can check progress as:
- List of completed items from functional specification (“product backlog”) with planned duration and customer value indicated
- List of tasks planned for the current sprint (“sprint backlog”)
In addition, there are daily meetings, 15 minutes every morning, at which team members share information on current problems and re-identified circumstances.

Pro and contra SCRUM for consulting

In comparison to the “waterfall” SCRUM will provide the following advantages:
- Each month the customer receives and begins to use the results of our work for a month. The risk that at the end of the project the results cannot be used is minimal;
- We can hire well-known professionals, and fully utilize their potential, even when working in a team;
- Any idea of the customer or consultant, arising in the course of the project can be used if they have advantages compare to the original technical specification.

In comparison to the “cowboy consulting”, we also get the pluses:
- We can use the scheme for a project which requires a team of consultants. Moreover, we do benefit from the use of consultants with different specializations.
- We know exactly the status of the project and it is unlikely to lose a client due to the fact that the situation got out of control.

Do I think SCRUM methodology ideal for the introduction of the software? No. The ideal methodology, I think, not the three-and five-letter combinations but common sense. You can think of a situation where the project pozarez need authoritarianism, the rapid adoption of clear and binding for all members of the team solutions or developing solutions that can not be realized in a single sprint.

Nevertheless, I believe SCRUM very interesting approach to the management team and objectives, and if you’re interested, then I suggest you download and read the Henrik Kniberg’s book “Scrum and XP from the Trenches”.