Planning the IT consultancy |
What I tell you three times is true.
Lewis Carroll, The Hunting of the Snark, first published in 1876, Macmillan, New York 1891.
There are always at least three sides to a consultancy assignment. There is the selling the assignment; there is the actual doing of the work; and then there is the getting paid. This chapter is about preparing for doing the work, which is actually a very demanding and critical part of any assignment.
7.1 IT consultant as a welcome friend
Overdoing the planning
When you read this chapter it is important that you take into account the appropriate level of planning which you need for your own particular assignments. No one will ever give you any credit for being overplanned. Over-planned means having flow charts and bar charts showing every detail of the work broken down perhaps by the hour for weeks ahead. In fact being too well planned is sometimes seen as a sign of not getting on with the real work – perhaps the consultant is putting off the start of the job.
Before you can plan the assignment you will need to get to know the organization a little as the way you will work will depend on how much help you will get from members of staff. The amount of this help will vary substantially depending on the environment in the organization. The environments in which the IT consultant will work can differ enormously. Sometimes the client organization can be very welcoming and very hospitable with the proverbial red carpet rolled out for the person who is coming to help sort out some problem. The staff often know when things are not going well and they are also often aware that for just some reason they can't sort it out for themselves. They need an outsider to help and here the outsider is perceived as a welcomed friend.
7.2 IT consultant as a threat
On the other hand IT consultants can find themselves in quite the opposite circumstances with their presence being resented as it is seen as threatening to the members of staff of the organization. In such a case the IT consultant can be treated with hostility. Consultancy assignments work best when the organization's staff is highly cooperative. They can easily fail if the staff is antagonistic. In fact, every IT consulting assignment represents the organization outsourcing part of its work. In most cases this work will usually be outsourced only if the organization is incapable of doing the work itself. This will often occur if there is a shortage of skills in the organization or if the current staff complement is so stretched that they just can't find the time to do the work themselves. Thus as an IT consultant you may well be plugging a gap for the organization. Sometimes the staff can see this as the management refusing to expand or promote people internally or just manipulating head count rules and this can be unpopular. It is simply the case that consultants are not always welcome by the regular workers. In such a situation you may have to be especially diplomatic in the way you plan and conduct the work.
7.3 Cooperation with staff is vital
… THE EXTENT TO WHICH THE CONSULTANT CAN SOLICIT THE COOPERATION OF THESE MEMBERS OF STAFF
Even where they are welcome the IT consultant will frequently have to work with a range of different people from the organization and one of the critical success factors for the assignment is the extent to which the consultant can solicit the cooperation of these members of staff. Thus one of the issues to establish during the assignment planning is who are the key members of staff with which you will be working and what is their attitude to this consultancy assignment. This identification of the assignment stakeholders1 is a fundamental step which is often ignored and which can produce complications later in the project. One of the problems that arises is that if all the stakeholders are not supportive2 of the project then the consultant may find that he or she does not have appropriate access to these people or to others who directly report to them. Consultancy projects cannot succeed without access.
Of course the doing of the work is a direct function of what exactly has been sold to the client and as you will have seen in Chapter 4 there are many different levels and different types of IT consultancy that you could sell. With this array of possible IT consultancy projects it is not easy to provide detailed generic advice on the subject of project planning. Each IT consultancy assignment situation is quite different and thus each and every consultancy project has to be planned and managed differently. Nonetheless there are a few general pointers that may be given in order to make the process of completing the project a little bit easier.
A signed contract or letter of appointment signals the start of the real work. But before you dive into the deep end it is really worth your time pausing to reflect on what you have to do and to plan the work in some detail. It is clear that one of the reasons that IT consulting assignments can get into trouble is due to the lack of reflection on what is actually involved or required to achieve the objectives before rushing into the work.
7.4 Covert objectives
Sometimes there are covert objectives or agendas within an assignment and if this is the case the planning phase of the project is a suitable time to discuss such issues. Some covert objectives are trivial such as requiring the IT consultant to give advice on career development to the project sponsors or client manager, in addition to the objectives stated in the proposal. On other occasions a covert objective could be to help a client manager find another job. This can be embarrassing to you as a consultant as you will not want to be associated with your client losing a member of staff. But it is usually not that difficult to get around this type of problem. Just give a fairly objective opinion about the job market. However, sometimes the covert agenda can be quite tricky. The consultant can be employed with the idea that he or she will end up covertly or perhaps even explicitly recommending that a member of the client staff be dismissed or perhaps a whole department should be closed down. When this happens the consultant is placed in a difficult position and there may not be an easy way out.
THIS CAN BE EMBARRASSING TO YOU AS A CONSULTANT …
Attitudes towards consultants
Sometimes consultants can be seen by members of staff of the client organization as an admission of failure. This is because they feel that if they were doing the job well there would be no need for outsiders to be involved in their firm. Fortunately this attitude is less prevalent than it used to be. Nonetheless the IT consultant needs to be aware that not everyone in the organization will welcome his or her presence. Sometimes a friendly and helpful attitude on the part of the consultant can go a long way to alleviating this but other times this will make no difference.
Of course even when the project objectives are not covert difficult situations can arise. IT consultancy assignments are often seen as being the precursor to change and as you know change is not always welcome in organizations. This is especially true when change is being led or spearheaded by an ‘outside’ consultant. It is therefore essential that the sponsors carefully explain the objectives of the assignments to all the stakeholders. The IT consultant may well have to concentrate on being accepted by the other staff. High on the list of skills here will be communication, team building and even motivation. This can be very demanding or even tricky work indeed. It can also be very time consuming and it is important that these confidence-building activities are properly estimated and costed in the proposal. However, this emphasis on people management will not be the case for all IT consultancy assignments as some projects can be largely technical or even routine.
It is important to remember that every IT consultancy assignment is a project with a set of specific objectives, a starting point and an ending point and as such it will follow the standard project life cycle. The main objective then is to manage your consultancy work during the whole course of the project life cycle. In simple terms this means following the well-established formula for this type of project work which is to plan, organize, motivate and to continuously control.
7.5 Project planning
THERE IS A STANDARD APPROACH TO PLANNING
There is a standard approach to planning a project and this involves identifying all the individual activities involved to achieve the objectives, then developing a work breakdown and creating a work plan. In the case of IT systems development projects, identifying the stages or phases of a project can support this. Thus there will be a feasibility stage, an analysis and specification stage, a production stage, a delivery stage and a finalization stage. It is of critical importance that you have a clear vision of what you have to do in each of these stages. As already mentioned it is indeed tempting to start the work immediately, but experience has shown again and again that if you jump into the work of the project before doing the planning correctly you will probably get the job muddled and you may end up without a satisfied client or having to do the work twice or even three times. In the context of an IT consultancy assignment most of the work of the feasibility stage should have been done at the time that the proposal was being drawn up. In a number of senses the proposal can be seen as a very high-level master plan, which includes the feasibility study. In addition to feasibility details, i.e. cost and benefits, etc., the proposal will also include critical items such as a precise list of deliverables and a timetable of when the work will be finished. All of this is needed to produce a detailed plan for the project.
7.6 A work breakdown schedule
Thus the first step in any IT consultancy project is to revisit the proposal with a view to extracting a detailed list of the actual deliverables required and the date by which they have to be completed. The next step in the planning process is to specify what are the precise activities or work elements that need to be completed in order to produce these deliverables. This is sometimes referred to as creating the work breakdown schedule or it is even called chunking the project. It is also important at this stage to specify the length or duration of each activity and also who is the person responsible for the achieving of the result. This work breakdown schedule is shown in Figure 7.1.
Figure 7.1
Typical work breakdown schedule
7.7 A project management network chart
When this is completed the next task on your agenda is to determine if any of these activities are dependent on other activities. The key question here is what activities or work elements can't begin before other work elements are complete? To help answer this question you need to examine the resources required by each activity. At this stage you can then associate with each of these work parcels the type and amount of resources that you will need to achieve your activity objectives. As you can see these steps actually constitute the building blocks required to set up any project management network chart. Once this has been done then the critical path through the network of activities may be calculated.
An example of a project management network chart is provided in Figure 7.2.
The project management network chart is the first step in preparing a PERT diagram which would involve multiple estimates of times, normally the maximum, minimum and most likely periods, required to complete each activity in the network. This provides considerably more information about the management requirements of the project. Where complex projects are being undertaken it is possible to sophisticate this diagram considerably with the use of minimum and maximum and most likely estimates for costs and other resources as well as durations mentioned above.
Figure 7.2
A typical project network diagram for an IT consulting assignment
For a relatively small IT consultancy project this work can be done by hand in a few hours but for larger projects there are software packages available. The offerings on the market for project management are considerable ranging from simple PC-based systems costing only a few pounds to very complex midrange computer systems costing tens if not hundreds of thousands of pounds. The main advantage to a small start-up IT consultant in using a project management software package, even quite a simple one, is that once the project details have been entered on the computer it is usually easy to change the estimates and parameters of the project. Having a suitable project management software package will allow you to easily do what-if analysis on the timetable and see the real impact of proposed delays and changes.
Producing plans
Projects nearly always turn out to be more complicated than they first appear. There is simply a high degree of unpredictability in this type of work. The history of projects is littered with overrun on both time and budgets. It is for that reason that it is very useful to use tables, bar charts and network diagrams to describe what it is you need to do and how you will actually do it. The precise type of table or diagram you choose to use is entirely up to you but you will be much better off with some of these than with none of them.
Preparing a project management network chart for an IT assignment has often led to some surprises. When the project management network chart is completed some IT consultancy projects reveal the sobering realization that far too much has been promised for the fee quoted. This happens because being generous, or perhaps put another way overcommitting and undercharging, is seen as a sure way of getting a contract for an assignment. However, getting the contract can be very far away from delivering a successful job and getting paid. There are many dangers in this strategy for obtaining work.
If you have promised more than you can easily achieve then you are likely to have to work longer and harder at the assignment than you may have planned. It is very unlikely that you will receive any sympathy if you go back to your client and admit that you hadn't quoted correctly. This is almost certainly true at the outset of the project. Perhaps as the project proceeds and you establish a good relationship and good reputation with your client, you may be able to argue that the project has actually expanded and that you now need more time or more money for your efforts.
On the other hand you may just have to consider the undercosted and thus underquoted job as a loss leader and be prepared to feel compensated for any shortfall in profit by being able to bid for and hopefully win new IT consultancy assignment from that client and others.
7.8 Bar chart diagram
Besides producing the project network diagram you might also want to produce a bar chart showing how the work is distributed during the project. This chart is sometimes produced instead of a project network diagram as it performs more or less the same function. An example of this bar chart diagram is shown in Figure 7.3. This is useful as it clearly shows3 when various activities will overlap and appropriate arrangements can be made for these busier periods in the project. There are a large variety of other project management tools available to graphically represent or display the project plans and consultants will quickly decide which of these they personally find the most useful. Two more will be shown here.
Figure 7.3
A typical bar chart for an IT project
Figure 7.4
A typical project work breakdown chart for an IT consulting assignment
7.9 Project work breakdown chart
IT consultants working as their own project managers will sometimes like to have a project work breakdown chart such as the one shown in Figure 7.4. This diagram has the advantage of clearly showing the timeline as well as the milestones (which are defined as especially important work elements or groups of work elements), actions, objectives and stakeholder involvement. It is a very useful document to portray a significant assignment that is conducted over a long timeframe. A particularly useful aspect of this table is the fact that milestones and stakeholder involvement are shown. Milestones represent key stages in the project and these are often delineated by special deliverables. It is important to ensure that if the project is to be delivered in stages that as many of the stakeholders as possible participate in approving the deliverable.
7.10 Making sure resources are available
Having produced either a project network diagram or a project work breakdown chart, which outlines the activities required, the next step is to ensure that all the necessary resources required to achieve these objectives are available. If you are a start-up IT consultancy business then you may be the only member of your team. But it is unlikely that you will be the only human resource – as mentioned above you will probably be working in collaboration with others from within your client organization or maybe other suppliers to the client firm. If this is the case then they need to be approached in order to ensure their understanding of their role in the IT consultancy project and to confirm their availability and then schedule them into your plans.4 All this work is then compiled into a detailed work specification document.
Figure 7.5
A detailed work specification showing deliverables, activities, individuals and dates
For anything other than a very small project this can take some time and require some effort. Figure 7.5 shows a more sophisticated work breakdown document, which contains three columns for details of resources. It also contains a column for details of the estimated start date and the finish date of the project.
If you are beginning a large assignment you may have to put several days aside for the planning while if the project is a small one then you might be able to produce the plan in a few hours.
With a completed plan the work required to organize for the project should become fairly clear. In many cases, for the IT consultant, getting organized is mostly about his or her time management. There are numerous frameworks and methods for managing your time effectively and it is important that you are familiar with at least one of these.
The question of motivation then becomes a key consideration and in this respect the IT consultant needs to ensure that he or she is not only self-motivated, but also able to offer leadership to the other project stakeholders. To be confident of being able to do this the IT consultant has to build up a trust relationship with these individuals. The extent to which this is necessary is clearly a function of the specific assignment that has been undertaken. In practice motivation can in some cases be critical to the project's success and in other circumstances it is a more minor consideration.
Finally with regards to controlling the project, meeting your project targets is crucial and you need to be able to obtain regular feedback so that you can ensure success. Control is about knowing how the project is proceeding, ascertaining if it is deviating from the plan and taking appropriate action.
Whatever the project the consultant will be partnering with the firm and its staff and perhaps its suppliers to achieve a set of objectives. Partnering really means sharing and thus there is a continuing and compelling need for the IT consultant and all the stakeholders to be as open as possible so that every one knows where they are and what is happening.
When difficulties arise it is important that they be highlighted immediately and that solutions be found before they become crises.
7.11 Project risk assessment
As a final step in planning the assignment it is useful to conduct a project risk assessment. The essence of risk assessment is to be able to anticipate the various things that can go wrong with a project before they actually happen and thus before they become a problem. Once the problem issues have been identified it is clearly easier to make plans to either avoid the problems or to minimize the impact of them if they eventually occur.
This is quite a vast subject in its own right and only a very high-level approach to this subject is discussed here. For a small project a risk assessment could be conducted in as little as one hour – for a larger project it could be a several day subproject in its own right.
The objective of a project risk assessment is to try to determine what can go wrong with the project and thus cause it to fail. Clearly the list of things that can go wrong will vary by project but there are some generic issues that should always be considered.
These risk issues fall into three groups:
1 The client
2 The work
3 The deliverables
7.11.1 The client
One of the realities of consulting is that clients can change their minds – even after a contract has been signed. Sometimes this is advantageous as it means extra work. In such a case the IT consultant will add the new aspect of the work to the contract and quote an additional fee. But sometimes it can mean that the project is reduced or even cancelled. Thus ask yourself if you think that the assignment sponsor is really committed to the project. Is the assignment sponsor's boss also committed and what about his or her colleagues? Then try to make an assessment if the assignment sponsor is committed to the organization and what will happen if he or she leaves to find a better job in the middle of the project. When an assignment sponsor leaves the project can easily be shelved. Find out if the organization is in discussions with anyone about a merger or acquisition, as this can also cause the project to be abandoned. Also ask yourself if the client can go broke and what would happen if you lose a sizable portion of your fees. As well as doing the work you really do need to be paid.5 It is sometimes hard to say no to an assignment. But if there is a material chance that the job will blow up in your face or that you will not be paid, it is imperative that you do not take the assignment. Just do something else.
7.11.2 The work
The next step in the risk analysis is to ask yourself if you really want to do the work and if you can really do the work. Is the work doable? Is the assignment going to make the client better off? If not what will the client do when this becomes obvious? Are there any hidden work problems that may raise their heads and wreck the project? Is the project too big for you? Is the client too far away? Will you get bored with the work? Are you relying on others to do a major part of the job and what is the chance that they might let you down?
7.11.3 The deliverables
On the question of deliverables, are these too ambitious? Are there too many of them? Is the specified standard of the deliverables too low or too high? Are the deliverables sufficiently well defined? Are the various timeframes reasonable? Can you deliver without going broke? Does the client really know or understand what these deliverables are?
The final question is to ask yourself if for any reason you wish to discontinue the project do you have an acceptable escape clause? Some contracts allow for both parties to terminate the contract within a given period of notice. Other contracts may ask for a large penalty payment. It is worth knowing this in advance.
Think through each of these questions and reassure yourself that your project is relatively low risk or if it is not that you can actively do something to help reduce the risk. Don't just stand there and watch the risks turn into problems.
7.12 Summary and conclusion
It is not easy to succeed with an IT consultancy assignment. There are numerous things that can go wrong. To help minimize problems it is really worthwhile spending some time planning an IT consultancy assignment. There are often many issues involved and to ensure you have the best chance of success put time aside to work out what challenges you face and how you will master them. Such time spent is a very sound investment and can really improve your chances of success.
Always remember that it is the client who will decide if the project was a success or a failure.
7.13 Checklist
Things to think about when planning the IT consultancy assignment
1 Create a detailed list of the required deliverables.
2 Put a delivery date against each one.
3 Break the work down into sets of logical activities.
4 Put a time estimate next to each one of these.
5 List exactly what resources are required for each task.
6 Create a work breakdown schedule.
7 Create a project network diagram for the assignment.
8 Perform risk project analysis by trying to foresee what things could go wrong.
9 Make contingency plans for those issues that could cause you trouble.
10 If there are too many areas of potential trouble are you able to refuse the assignment?
11 Are you completely clear as to how the client will measure the success of the assignment?
12 Is your client fully committed to the project?
1 Ideally IT projects should have stakeholders but in reality it is often difficult to engender adequate commitment from the individuals who should be the stakeholders. Therefore some would say that participants may well be a better word to describe what actually happens.
2 Not only will some of the stakeholders not be supportive but sometimes they can be down right antagonistic to the project. Where this happens the IT consultancy project may well be in danger of failing. The main recourse it to go to the bosses of the individuals concern and see if that helps them become more cooperative. However, consultants are often particularly vulnerable to company politics which can simply scuttle a consultancy assignment.
3 Bar charts often use colour very effectively to show different activities and the critical path (the critical path is defined as that series of activities or work elements in which there is no slack, i.e. if any element of this series of activities is delayed the whole project is delayed) is often shown in red.
4 It is usually not a good idea to approach members of your client organization from whom you need assistance before you are correctly introduced to them. The project sponsor needs to make sure that this happens in the correct way. If the organization's protocols are not followed you may well find that the individuals with whom you need to work on the project will just not be available. Don't take any chances with this. Make sure that the right channels are followed so that all the right people are bought into the project.
5 There is absolutely no doubt that these are all very difficult questions and issues and that it will be no easy matter to obtain answers to these questions. However, even if you cannot find answers it is worth being aware of the sort of things that can go wrong and result in a terminated project.