How important is planning?

Planning is critical. Without planning there is little chance that you can every complete your project, let alone complete it on time. The act of preparing a plan, if done correctly, will uncover the issues and risks, provide the bulk of key data for your estimation efforts, provide a clear view of what resource is needed when and lots more. It will also help to discover the dependencies that may exist with other projects and activities.
Once prepared, the plan gives the team a better view of how their efforts will come together and points out the need for communication in critical areas.

How important is the plan?

Much less important than the act of planning, but still very important. The reason I say this, is because:

1)  It is rare to be able to complete a first draft plan and then not have to make any adjustments. Most plans develop as they go along and reach a baseline when well into the project timeline. The most obvious examples of this are projects that involve investigating a problem designing a solution and then finding suppliers to deliver it.
You can allow extra time at the start in the hope that it is definitely too much , but even then, the chances are that you will end up cutting your plan back.

2) Risks and opportunities are a part of every project plan. Sometimes risks come to fruition and they affect the plan profoundly, sometimes opportunities come along that are either too good to miss and causes change of requirements, or  reveal, or cheaper a faster way to get it completed.

In either case, the initial plan will have changed. To live in denial of this as many commentators on project management still do, is a huge mistake and will always be counterproductive.

E.G. If you become so obsessed with meeting a specific date that you are prepared to pare away key features, there is a strong likelihood that the project will fail entirely. The answer is to treat the plan as a guideline and treat planning as an ongoing task.

Starting a new venture is much more volatile than starting a project, but it is also higher pressure with greater risks and a lot more to lose.  They don’t actually tear up the plan of course, they adjust it and maintain it, but the discussion served to get their point across that management is about managing and adapting on a daily basis, not stubbornly following a plan regardless.
Managing a project should be driven by the business case in the same way that a new venture is driven by reaching a profitable trading position at some point.

Features - Deadlines -Budgets - ROI

Here’s where it all happens.  A project will have a goal and that goal will usually be a financial one though not always measured in financial terms.
For the sake of this example I will assume that the project is a cost cutting exercise with a specific financial aim. Right at the beginning, the same ground rules should have been laid down such as; What saving are we aiming for?  what investment are we willing to make? What is the maximum our budget can rise to, or the minimum our savings can drop to.?

This latter question is best answered in terms of ROI and in fact, in most commercial organisations the answer will be worked out on the basis of how much ROI exceeds  ”Cost of Capital” in order to qualify the project as “best use of capital”.

Once this understanding is in place and the variances have been explored and allowed for, the business case should clearly show the expected returns and the variances that are allowable.

The project now has an ambitious goal (maximum realistic returns) and realistic allowable variances. The importance of these variances is not to make the project management team relax, but to assure the sponsors that their investment is relatively safe.

MSF, the Microsoft flavour of project management introduces a very useful concept known as the project triangle. It is a simple triangle with the three corners being occupied by Features - Resources - Time.

The significance of the triangle will be obvious to any mathematicians reading in that only one corner of a triangle can be fixed unless you want all three to be immovable.
This is why the prioritisation of concerns is a valuable part of stakeholder alignment. If stakeholders are allowed to follow their natural instincts and demand that all three corners are fixed (two fixed corners means the same thing) then there is no room for the project management team to steer the project out of trouble.

A realistically aligned project will choose one of Time, Features or Resources to set in stone and the other two will remain fee to move.  This way, if time is fixed, then a PM can choose between increasing resources, or decreasing features in order to hit the target (ROI)

This example is one of the simpler ones, but it is indicative of the ills that beset many projects right at the beginning and rob them of any real chance of succeeding, or being seen to succeed.

Defining the scope/budget/resources

Once again, with the ROI in mind and the statement in the business case that based on initial studies, there is a strong likelihood of success, the task now arises to define in more detail the features required to deliver the expected benefits.

Having defined the features, accurate costing has to be worked out on the basis of supplier estimates, internal efforts and other costs, with adjustments for risk, all of which will rely on your emerging plan.
 Another sanity check at the end of this planning phase should check whether  the cost and time estimates are still within the constraints initially set for the project and whether it has a healthy amount of slack remaining to see it through to a likely successful completion.

This exercise of working up plans from draft to more detail as the work progresses form an outline business case through to a detailed contract with suppliers and a detailed plan of implementation with all the appropriate slack allowances  and a rigorous risk assessment will often take up half of the lifecycle of the project or even more and some projects will be abandoned when it becomes obvious that there is little likelihood of success. The number of “stage gates” (sanity checks) should be agreed at the start on the basis of how well known the territory is and how volatile the estimation is likely to be.

The illusion that a project board can put some dates (when we’d like it done) and amounts(how much we’d like to spend) on an A4 sheet at the beginning of the exercise and that perhaps a year or more later, a project team will deliver exactly what was asked for on that sheet, within exactly that amount and on that date is really a surprising error of judgement, but it still happens and contributes strongly to the list of project failures that appear on the Standish report and other investigations.

How to go about project planning

Planning should always be done by starting at a very high and general level, applying a sanity check and then drilling down not too far to the next level to repeat the exercise.
Planning should always resist the temptation to go into great depth in one specific area while remaining at a high level on others with one exception.

Plans should not be in extreme detail a long way in advance, because the likelihood is that when that time draws closer you will find yourself redrawing them and the effort has been wasted.  As planning continues to drill down, a plan should be retained for each level of detail and when the detail highlights an error in the high level plan, as it frequently will, then the high level plan should be adjusted.

The commonest method of estimation to begin with is to break the project down into products.
These products can in turn be broken down further until they reach a level whereby they can be more easily estimated and planned and later assigned to teams.

Out of this comes a product flow diagram that describes the order in which these products must be completed in order to take account of interdependencies.

Calculating critical paths ( the longest path you can follow)through the products and then amongst the products, the project manager can get a much closer view of the true schedule of the project.

Using PERT to make a high level allowance for uncertainty adds a further level of sanity check to the emerging plan.

Some of the issues that commonly affect project plans drawn by the unwary include :

1. The calendar is not taken into account when calculating for tasks in the plan, e.g seasonal breaks, Summer holidays and other disruptions that happen every year.  Key personnel  disappear and dependencies become critical.
Make sure you discuss each team members responsibilities and schedule with them and get agreements.

2. Suppliers work to their own schedules and regardless of what they agree,  they will place commercial concerns first and may not follow your plan.
Ask them for their plan and question to satisfy yourself that it is thought through. If you take part in the contract negotiations, try to place some extra responsibility on them to deliver on time, or warn you in advance.

3. Estimates from technical people are accepted at face value and in reality they are vastly underestimated 80% of the time.
Get second and third opinions, look at records of old projects and as a minimum double the estimates from the best people and use factors as high as five for others.

4.  There’s gaps between what the supplier delivers and what the internal team have allowed for.
e.g. Inexperienced people might assume that a system can arrive, be plugged in and start testing.
Clear acceptance criteria may not exist and there may be problems agreeing acceptance.
Cut over from an old system to a new one may not be catered for.
 This list can grow quickly. If you are not an experienced systems person make sure that there is one in charge of this part of the plan.

5. There may be several suppliers and communication between them may be less than ideal. Often this situation leads to gaps where nobody is responsible and the work grinds to a halt, or even enters dispute , or litigation.

Make sure you hold joint planning meetings and get sign-off to theses joint plans

6. Beware Johari’s window. What you don’t know you know is a terrible waste, so consult and consult again. What you don’t know you don’t know will come back to haunt you, so involve everybody in risk management sessions and try to be ahead of the game, have sufficient slack and keep stakeholders informed of the true position.

7. Over ambitious, or over confident plans create a sense of expectation amongst stakeholders that changes to discontent when the plan slips. Perfectly good projects are often deemed poor projects as a result of this very mistake.

Take the time to estimate risk realistically and maintain realistic slack for the high risk areas of the project.

So in summary:

1. Planning is critical and underpins everything, but it is an ongoing everyday task, not a game of snakes and ladders.

2. Managing projects is primarily about handling and working with uncertainty to remain within agreed, acceptable boundaries, not shooting a silver arrow at a precise point.

3. Planning for well known items is easy, beware what you don’t know, this is where you will get caught out.

4. Risk and opportunity go hand in hand, avoiding risk is no more important than spotting opportunity , but it requires an open mind and a fluid approach to planning.

5. Start with an achievable goal, make sure it is well understood and shared  and keep it in front of mind at all times.

Build a dungheap and the insects will come

I just left a meeting where we discussed a large and complex programme of work and my mind kept going back to recent discussions about why projects fail. We have been talking about project managers who stay in the office playing with gantts and charts and PMs who know nothing about their subject matter, but see themselves as traffic coordinators. These are real concerns and they are at epidemic level at least and need to be discussed and resolved.

Take one step back from this discussion,however and place yourself in the average programme office.

If the Project manager rarely sees the battlefield, and spends his time constructing fantasy plans without ever checking with reality and assuming that things will stay the same, then imagine how far removed the average programme manager is.
Today I watched just such a Programme manager going through a programme plan and showing the position of each project and of each tranche and giving a thoroughly convincing performance, but based on a few conversations with project managers before I went in, things were not at all like the programme manager’s presentation suggested. Not only was he highly removed from the truth about the various projects, the truth of which was obscured behind vague and even pointless KPIs, but he had no idea of the true situation within any of these projects. One project had reached it’s milestone just ahead of the presentation by launching something totally flawed in the knowledge that it would not be found out for a while and if they hadn’t fixed it in the meantime they would deal with it then and feign ignorance of it. The KPI was declaring completion, not passing though any realistic test of completion.

How can you risk manage a programme without total honesty and a powerful beam of light?

I dread to think of the consequences for his programme of a key project on the critical path getting into serious trouble. If he is measuring the programme with this type of metrics and this lack of control, what chance is there of coming anywhere close to success?
As it happens that project is a critical one and it can stop the entire programme., it should be the focus of major attention until it is out of trouble or the whole thing is abandoned.

There is no difference between this handling of projects and programmes and the commercial practices of reporting false profits to keep shareholders happy and  keep the capital flowing your way.  We have created the conditions for failure and it will continue to happen regularly just as a pile of compost left in the garden will attract plant life.
Is there a realistic answer on either front? I will have to think about this one.

One note in my notebook is quite revealing, no member of the board was present to learn how things were going.

Ignore the new vocabulary and you’ll find nothing new in the concepts.

If you have heard me pour scorn over some of the claims made for agile, you may be surprised to know that I’m an agile practitioner with some considerable experience and not at all adverse to the approach.  That said, I always repeat the words of my agile mentor Keith Richards (no not him silly) when I asked the obvious silly question. He said ” It’s horses for courses.  When you turn up for training we assume a certain level of education, intelligence and experience”.

OK so what is the big noise about. Well the underlying promise of agile emerged back in the seventies soon after the first Standish report when some of the industry leaders cooked up an alternative to the waterfall way of wasting money.
The theory and indeed the practice is totally valid when followed with a level of honesty.  You tell me how much you can spend, or how long you have and I’ll guarantee you a working system.
Note the difference from waterfall where you have two options: fix both budget and time and have a failure nine times out of ten, or fix  just one and reduce the odds by 2/3.(MSF).

Agile delivers on the promise when billed honestly and executed  honestly.
Here’s the metaphor.  Say you meet with your co-directors and agree that right now the thing that will  accelerate you to your goals is an very large extra table  in the boardroom with a tiny door and spiral staircase and you have only £n  to spend, or n months to deliver it. I will discuss your needs at length, then I will come back with a proposal that looks like this.

The minimum required to make this work is a top and thee legs. You don’t need four to make a table work, though I agree it would be nice.  It can’t be bought and even the top has to be constructed on site.
The legs are standard things and fundamental so I will order three of these and have them delivered.
We will start making prototypes using scrap wood  for legs and sticking planks together until we have a table that is just stable enough and functional enough to meet your needs.

This we are confident we can achieve within your constraints, if we have extra time or budget, which I expect we will have, we can add a fourth leg, or smooth it over, or add a coat of varnish. You can decide when the time comes, which is more important. That’s it. No miracles, no free lunches, just less pontification, more action and a product that is fit for purpose, if not always entirely pretty.

 When you wouldn’t use agile.

You would never use it to build a space shuttle. That type of project requires a right first time approach.  I shouldn’t joke about a tragedy like that. There can never be a serious consequence of getting it wrong first time. You shouldn’t use it unless you are bought in fully to the three legged table, if your mind is set on four, stick to what you know. If you are buying in the team either as contractors or a service company, it is risky, because highly competent  people is a prerequisite.
If your main motivation is to be involved on a day to day basis as opposed to making a decision up front. It is poison, keep away.

IT investment for the smaller business
Why the Smaller business holds all the cards
Where has alll the money gone
Requirements gathering the first big mistake
Contract negotiation and on we go
Whose fault is it anyhow ?

23% of European projects cancelled, more than half overran by 50% or more.

When projects grow to any size, they invariably lose sight of the basics and especially they lose sight of the goals.

In the above study the authors uncovered weaknesses that have reached epidemic proportions, i.e inability to distinguish the critical success factors from Prince 2 speak ( total faith in methodology alone). Wrong KPIs from day one.  Inability to define and agree requirements.  Poor programme and business management leading to people believing they have done well when in fact they have missed the target completely, or that they are failing when in fact they are performing well.
Poor estimating of cost and time leading to inaccurate plans and poor management failing to follow good plans.
The wrong man in charge. The wrong reason for starting in the first place.  Bad decisions made for the wrong reasons.
Unspoken political issues that were well known from the start, but could not be spoken of openly.

The most common failings are at the early stage and they are failings to understand:

1. Failing to understand what is best for the client. It doesn’t matter who is responsible for identifying and solving the problem, client or trusted adviser.  Things will go badly for both sides of the relationship unless it is done well before proceeding to delivery phase.

The challenges here are well understood, new technology in anything from fighter planes to productivity software is a challenge to understand, explain, evaluate, risk manage and decide on.
When it comes to an independent adviser this can be a little easier, but when the adviser is the supplier then it is more difficult to evaluate the accuracy of the material before making decisions. One of the biggest root causes of failing and vastly underperforming projects is poor choice of solution either through misunderstanding the problem, the operating climate, or the proposed solution.

The client has to take responsibility here, there is no alternative.

2. Understanding the problem and knowing what solution is chosen, but not understanding the macro and micro detail of exactly how the solution delivers and whether it really will fit in, switch on and work well enough to deliver on the promise.

Let’s say our customer is solving a scheduling problem and has agreed to invest in an automated scheduling solution. At this point it is hard to fault the logic. This is macro level. Now at Micro level our customer will have discussed certain things like how it interfaces with his ERP system and details like how it chooses who to send a particular emergency to.  All the big stuff and all the sexy stuff tends to get discussed.  What nobody has looked into is whether this system can deal with the fact there are many jobs where a dozen or more customers have to be visited at once in close proximity ( a warden controlled environment for the elderly is just one case).  This is the type of thing that is completely missed out on and grinds everything to a halt at some point, sometimes to the extent of scrapping everything and starting again, but more often by adding to the time and budget estimates, or dragging down the project slowly by reducing the benefits and spoiling the expected return.

3. Understanding the problem and the solution, but failing to understand the ambient climate that affects whether an expected outcome can be reliably predicted, or whether a more conservative approach is required, or perhaps and “all-in” gamble when there is nothing to lose and all to gain. Certainly there is a marked difference between the decisions being made today and those being made prior to August 2008.  I saw EDI solutions implemented at enormous cost at a time when a web page with HTTPS could have solved the same problem.

These three aspects are just small but very important reasons why projects will continue to struggle until they are taken more seriously.

Working relationships have to be enabled and supported, or they will hover close to litigation.

There are no big companies, just people who work at them and most decisions are based at some level on selfish motives. More often than not a supplier’s representative has to meet certain targets and will play the game to defend his margins.

In order to meet you half way he has to feel very confident that you can be trusted and he has to be motivated by gain. Don’t read this wrong, the gain I am referring to is the gain that results from satisfying his superiors, or exceeding their expectations, the gain for a customer representative is very similar though it will often be motivated more strongly by personal risk aversion.  Few organisations reward risk taking and even fewer forgive the risks that mature.

Easy solutions with negative undertones

The easy solution for the sales director, or suppliers project manager is to record what you ask for, make sure it is sufficiently close to what they are offering to keep them on a safe legal footing and then proceed in the knowledge that whenever it goes a little wrong, they will be very sympathetic and give you a bit of a discount on the extra work you needed. This strategy places all the risk on the customer and the further in the he commits the business, the less likely he will be to walk away and admit defeat. This strategy has developed into an art called “contract re-negotiation” that has begun to appear on CVs.

The easy solution for the customer project manager is to ignore the details and make it appear that he is placing all the responsibility for detail on the supplier. Then when it goes wrong they will wrangle and resolve it and he will continue to maintain his innocence and to castigate the supplier.

The correct solution is to negotiate the contract correctly from a position of enlightenment and to identify and spread the risk evenlySimplest case

The easy solution for the customer is to hire a red hot BA to document in great detail every aspect of the required solution, ask every question that needs to be answered and double check the fit with the business requirement, business strategy, prevailing conditions.  Having signed this off with business stakeholders, the risk has now been spread evenly and fairly.

The business makes a business decision and takes the strategic risks, the supplier works to a precise specification and prices the job accurately to leave an appropriate margin, the delivery team have only to concern themselves with identifying the risks that remain managing them attending to dependencies and keeping everything on track.
Any unexpected issues are easily categorised as such and there is a clear path for handling them appropriately.

More complex case

Many projects carry with them an element of innovation, this is the stuff of progress and it is critical not to smother it, but to do it well requires a marriage, or at least a fairly resilient affair between the business and the technology partner.

The answer is not surprisingly a combination of the two previous approaches. First of all a BA must do the job of defining the part of the project that is well understood in terms of business need and the supplier must bid for this as though it were the whole project, initially at estimate level.  The areas requiring innovation and carrying higher risk must be evaluated and risk managed so that a maximum cost and a likely cost can be established and the risk level can be well understood.

Once this is done an approach is defined that tackles the biggest impact risks as early as possible in order to allow an early exit if things go wrong.  Regular stage gates are planned so that there are opportunities to revise risk and cut losses early.  Managing the risk in this way makes this aspect of the project less likely to fail catastrophically and brings it out in the open early.  Working relationships tend to prosper in this type of environment and good relationships deliver good outcomes.

Risk management is like charity, it must start at home.

The first and by far the greatest risk to every project is the culture of the organisation.  As this report supports, many project managers turn a blind eye to political situations that can’t be discussed and proceed in the hope that all will be well.  Some of these situations include: mixed feelings in the boardroom and tripwires around every corner, Gadget freaks in the senior management who want to add on stuff they would like to play with.  Management who shoot the messenger, but can easily be fooled. People who get involved with the suppliers or their staff socially and undermine the project team.  There are many more examples of very serious risks that remain unspoken, but are responsible for a great many failures.

Previous installments

IT investment for the smaller business
Why the Smaller business holds all the cards
Where has alll the money gone
Requirements gathering the first big mistake
Contract negotiation and on we go

Well here we are, though dragging slightly due to the unexpected holdup when everyone was so inconsiderate as to take a long break in the Summer and get all relaxed. It seems like a very short time despite the months that have passed, but we are now nearing a milestone when the vendor delivers the systems to us and according to both the vendor’s project manager and the IT manager, we are expected to do something called UAT.  Of course it’s not written in law anywhere, but to our project manager, it may as well be because he is following the conversation two sentences behind and trying not to look too foolish.  The vendor is still driving the agenda alone and the IT manager is still sulking, but gaining in confidence as the project approaches his territory.

The problem with COTS purchases and traditional testing methods is just that.

Well, it’s just that the methods were designed for a world where teams of engineers spent months writing code and then began to stabilise it and introduce it slowly into the business environment until it was a stable release and a good match for the tightly defined requirements.  At least that was the theory, there were usually problems about interpretation of the requirements and about how the outcome was actually achieved, but at least the bits did fit together and they followed a well established pattern. Vmodel was and still is the standard.

 That was a simple theory, you had to created business requirements, the analysts translated this into designs, the developers translated that into systems, then it was refined to make it usable and fill the gaps in interpretation of business requirements.

Logically therefore, you tested the business requirements with stakeholders and got it agreed, then the designs with business analysts to make sure it was properly interpreted, then the system to make sure it fitted the design. Along the way, there had to be technical testing to make sure it could run on the clients environment correctly and then a bit of testing to make sure it worked well enough for testers to commit weeks or months of their time.
Finally you arrived at the point where you had a working system that had no major bugs and appeared to meet the needs of users and it was time to let them loose on it.  That was UAT.

It usually flushed out little bugs that had been missed, it also flushed out poorly interpreted requirements that just didn’t work in a live environment. Additionally, it served as a way to win over key users and pre-empt any likely resistance to the process change aspect.

For a simple explanation, that has taken a bit of effort and probably lost me some readers, but it’s not a simple business.

So how does our project manager apply this to a piece of kit arriving on a CD with a few minor customisations and integration endpoints?
Maybe not the million dollar question, at least not every time, but an expensive one often.

Our friend has no detailed requirements to work to, because the initial ones were not adapted, but instead, the sales guy sold an existing package and said it will meet the requirements you described. If our friend hires a tester, he will need to go to the vendor’s and ask them to help him list exactly what this system is expected to do for the client in order that he can test it.
Were he to do that, alarming as it may sound to many readers, at least a start would be made on understanding what has been agreed, what is expected by whom and what the likelihood is of all these stakeholders being in the same book let alone page.
Now I am not a sadist, despite what you may be thinking and I have no intention of bringing up the business case and the business goals at this point, our poor friend is in enough trouble already.

The IT manager is now beginning to ask awkward questions and making apparently unreasonable demands about some sort of complicated and time consuming testing before he lets us install our system on “his” environment.  Is he out to get us? He never really was supportive anyhow, because he felt he should be in charge.

So where have we got so far?

We identified the need for change and made a business case for investment of the businesses capital based on some modest assumptions sound process change and cost reduction due to efficiency and we got the go ahead to do it.  We have not tested these assumptions against the new system being proposed and we have no idea whether any of the goals will really be met other than a stirring presentation and “good feel” from the vendor’s sales rep.

We found a supplier that we felt we could work with and agreed a contract, we know of course that that contract was tipped 90% in favour of the supplier, but we hoping that all will end well.

We are now approaching eminent delivery just a little behind schedule, but nothing to worry about and we are very confused about the communications coming from the vendor’s team. We are expected to complete “UAT” in three weeks and then sign off acceptance and pay the final instalment for services and we will begin to pay the support and other fees immediately. This has a very final and serious ring to it.

We are gathering up a few people and arranging a room where they can sit and “play with” this system for a few weeks. Then hopefully all is well and we are done.

We have met our milestones so far, the budget is at or below forecast and the CEO is very impressed with us, let’ s hope these IT guys don’t spoil the party.

Next:

Whose fault is it anyhow ?

Previous installments

IT investment for the smaller business
Why the Smaller business holds all the cards
Where has alll the money gone
Requirements gathering the first big mistake

A shock for the project manager

In the last instalment we discussed the way in which a vendor had been chosen that near total disregard for the goals of the project in the course of making that decision. Now we will look at what happened after the decision was made.
The next agenda item directly after awarding the contract was to negotiate and agree details and on this occasion it was lead by the vendor’s legal team and the sales rep.  The atmosphere was very warm and jovial and nothing was too much trouble in the vendor’s quest to make the new customer happy.

So far so good

The contract was agreed just after lunch on day two and everyone went away with a sense of achievement. 
Deliverables were carefully defined and the acceptance criteria was very forgiving. It would have been clear to any pro that there was a lot of stuff not mentioned that would need to be done and paid for, but it was not brought up.  The bulk of the cost was loaded up front with a year’s licenses to be paid for immediately and support to begin charging on contracted release day.
There was an SLA, but it gave no guarantees of times to fix issues, only times to address them. The rate for professional services was a little steep at £1400 a day but it seemed academic.
The real problem with this contract was that it never referenced the now academic requirements documentation (In any case it was pretty useless) and
the contract revolves entirely around delivery of a certain feature set as described by the vendor in features language, not in business need language.
Success criteria is defined as delivering this feature set by a given date and to a given cost
At this point we have two teams involved; a project team that is now providing services to the vendor to get the job done and a vendor with the goal of delivering the described features and getting paid.   Our initial problem of lack of experience and know-how in the sales and marketing teams has never been addressed and is not on anybodies radar and there is nothing anywhere, either spoken or written to say that delivery of this feature set will solve the defined problems I.E. the business case has been forgotten. In fact the thing that really swayed the decion on which vendor to use was a very sexy system that lets  the user record telephone conversations and the hardware to make this work pushed up the cost.   
Here’s the shock for the project manager.
The sales rep is now cosy with another potential client and the project manager is now dealing with the professional services team tasked with delivering the project to  tight budgets.   Now he’s dealing with a real project manager and a hard nosed business man who survives by taking no prisoners and earns bonus by growing the contract value through extras. He is a past master at dealing out the rope and charging to reel it back in and he’s seen all the snivelling before. He is the essence of tact and diplomacy but his hand is firmly in the project managers pocket.

The roller coaster

Within two weeks of contract completion, the mood has turned frostier and it is clear that this is not precisely what the project manager had expected and hoped for.  Everyone is now locked into a roller coaster of milestones and budgets and the reason for it all is completely forgotten. That was handled in phase one, wasn’t it?  You get on in the corporate world by meeting milestones, not by delivering results and certainly not by making waves.

We are where we are

We are now on ride that won’t slow down until this thing, whatever it is going to look like, is delivered and we can start the job of making it work and getting people to use it so we don’t lose face.
Nobody who suspects the truth, if such a person exists, has the seniority or the courage to step out of the line shout horses@”!* and nobody with the authority or the presence to do something has any idea that things are not what they seem.

 In the next installment we will look at the the end game

About the author

Previous installments:
IT investment for the smaller business
Why the Smaller business holds all the cards
Where has alll the money gone
 Many seasoned project managers will start off a project by sending out his business analysis team to carry out requirement gathering.
Sometimes this is the right thing to do, in particular you should do this when you have a successful proven process that you want to automate using IT.  Requirement gathering then educates the IT people responsible for system design (the features) on what they need to achieve.
This is a different scenario, just think about it for a minute.  If we had the business case open and we had a succinct explanation of our goals and how success will be measured, would it not say things “like failing processes”, “lack of experience and knowhow” and would there not be talk of providing a new and better way and retraining people?

Here’s what actually happened.    
A Business analyst was hired to gather requirements and she went about learning how the business works and mapping all the tasks that people do every day. She was very thorough and presented it all back in neat UML diagrams with notes and she created a data catalogue to back this up.  An up and coming manager from the business then was appointed to find a supplier and deliver a system. He was instructed to report with final costs from shortlisted suppliers.

Off he went and began to invite various CRM vendors over to give presentations and answer questions.   They were given copies of the Business analysis in advance which some read and few paid much attention to.  Fairly quickly it became evident that this was a bit technical and he would have to rely on the vendors to keep him out of trouble and he quickly got it down to two people that he felt he could work with and asked them for quotes.  He had by now built relationships with these guys and they were advising him. The IT manager was also sitting on occasional meetings to make sure things were to his satisfaction.

He ruled out several vendors early on because their technology was not compatible.  He was a bit miffed that he was not in charge of this instead of someone who knew nothing about technology. It never crossed his mind that he knew nothing about business. He insisted on writing a features grid based on the business analysis and asking the suppliers to state whether they met all the requirements.

Eventually they chose a vendor that the project manager felt comfortable working with and that answered all the questions for the IT manager.

Perhaps this is a good place to finish this instalment and focus the attention on where we have got to from where we started.
We began with well defined business problems that required to be addressed urgently and which included lack of experience and know-how in the sales and marketing teams.  We ended up with a supplier chosen on the basis of the IT manager’s priorities and the Project managers relationship with the sales rep.
Par for the course.
At this point the budget has a debit side exceeding £30k and that takes no account of internal staff spending considerable time away from the day job.

Next week we will look at the contracts negotiation stage
  About the author

Part one - why?

Previous installments:
IT investment for the small businessman and novice
Why the SMB/SME holds all the aces when it comes to IT
In our last instalment we talked about the advantage an SME/SMB has over it’s bigger rivals when it comes to implementing technology, especially around the aspects of communication, business change and lack of red tape. 
Don’t let this reference to red tape fool you. It is mission critical to understand the difference between vital  process and red tape and it’s not always immediately obvious.
The key to cost cutting in any area is knowing what to cut. The word we are after is waste, but even that can be misleading.  In the world of Lean everything outside of the critical value adding moment is deemed to be waste, but nobody imagines that you can eliminate most of it let alone all.
The best approach is to look at where the money goes in a typical systems implementation.
Let’s take ACME  cash registers.
They have a turnover of 200 million and they have countless systems handling different aspects of their relationship with customers.  Nobody in the organisation has the full picture at any time bout any customer.
Sales people call with an Upsell proposition within an hour of the customer complaining bitterly to support.

• Customer enquiries get written on cards and handed to salespeople who then lose a percentage or forget to mark them up so 14% of leads are never followed through. (any of this sound familiar)
• The last time they tried a mass emailing they only had email addresses for 34% and two thirds of those were returned undelivered. This resulted in their IP address being registered as a spam house and for three months their emails were being destroyed by a robot and never arriving.

Ok this is just the tip of the iceberg, but you get the picture. The new VP of sales has read the riot act and reluctantly he has been promised that they will try and find some budget to help out. Where do we go now?
In our next contribution we will provide an insight into how not to approach it and the we will move on to  look at a simple model for getting this job done.
Requirement gathering the first big mistake

  About the author

I know you probably wanted me to tell you how unfair and inequitable the world is and how tough it is to be small. We’re in that sort of phase just now. Well you are going to be disappointed, but I challenge you to read on anyhow.
Not only is it easier, cheaper and less risky to implement state of the art IT, but rarely do your big brothers tap into the advantage effectively once they have implemented it. Now there is a new twist that puts the smaller business back at the cutting edge.

Small is beautiful when it comes to costs

When I rolled out a nine million pound IT investment for a government department, I spent more than a million getting the messages through to the workforce that things would be changing and preparing them and yet another million fighting the bonfires to get it rolled out and accepted.
When I rescued a large project a few years ago, they had already spent close on a million on feasibility and had got nowhere with it.
Implementing a mission critical system for a huge nationwide organisation, I got to roll-out stage and not even the CEO could make IT go any faster, we waited three months while they  put us off with new problems each day and they negotiated for increased budgets for running the system that would have supported a medium sized island, despite having agreed all of this previously at planning stage. Each slight effort from IT requires forms, a process and a very long wait.(Partly justified, because bigger IT comes with bigger risks).

Small is beautiful when it comes to change

Bringing about even fairly small changes in a very big organisation is slow, very expensive and not at all guaranteed.  The employees have no sense of connection to anything , or anyone, it’s just a huge employer and change is inconvenient. Customers have a stronger relationship with the brand than employees with their management and shareholders. Established employees can easily resist change without suffering any consequences and often do so just to prove that they can.

When a big business is forced to compete with small business on a level playing field, it is like a train attempting to  catch a rabbit.  Trains are only good for long straight and fairly even roads. While the train is moving the tracks, the rabbit is enjoying the grass on a greener slope.

Business case

The average cost of a feasibility study and business case for a large business today is estimated at around £60,000. There are more stakeholders with more complex propositions and communication grinds to a slow shuffle. There is usually little or no true big picture and everything you produce then has to be reviewed on the basis of, “do I really look like that that?” .I recently completed a feasibility and prepared a business case for a large SME/SMB and it cost just  £7k.
Rapid painless implementation
When that business described above comes to implement their plans, the system will be hosted on the cloud without a single click of a mouse by their IT department and it will be running and operational in a one day.
It will have world class back-up, disaster recovery, failover and  all the things an SME/SMB struggles to afford and  it will be maintained 24/7.
They won’t buy any hardware or purchase anything up front and their modest budget will be spent on improving their business to take advantage of the new system’s capability, communicating their requirements accurately to the service provider, training people to make their lives easier and their jobs more secure with this new super tool and getting their data into good shape to take maximum advantage.
 Dynamics of IT investment for the SME/SMB
 Where has all the money gone?
 About the author

Previously:

The advantages a small or medium business has  over their larger competitors and how they can save vast amounts of money in implementing high productivity software and gain the benefits faster.

1. It investment should never cost you money, it is an investment and the ROI should be clear.
 Build a business case professionally and then invest with confidence. 
The question to ask is; who would you rather trust with your capital, your own business, some investment bank, or maybe a fund manager?

2. Cash invested in your own business via IT systems or any other properly planned investment is always going to outperform any other investment and it remains within your control.

3.  In a free market economy, you always have to match the performance of the market leaders sooner than most of your competitors, or you are out of business. It’s not optional.  If they have automated successfully, you are at risk until you follow suit, or outdo them.

Types of IT investment

One thing every business man/woman or at least his/her CTO should understand is the dynamics of costs and returns  for different types of IT investment in different sizes and types of organisation and for different purposes.

There is absolutely no broad sweeping brush that can be used here and there are few reliable rules of thumb.  There are huge risks for the unwary and there are massive opportunities for the savvy, there are things that are not optional and things that are very much optional.

IT infrastructure versus productivity systems

The first big source of confusion is between the purchase or replacement of networks, servers and workstations, printers, operating systems and office systems like Microsoft Office.  The risks of a failure are dramatically less in this area and the potential to realise benefits and make gains are also much less.

Putting off the upgrade of workstations or operating systems by a year will rarely have any effect on bottom line unless you are losing time due to stoppages and unreliability.  This is an area where business cases need to be scrutinised with great care.

1.       Unless there is real risk of lost productivity, or very high maintenance costs, it is going to be hard to justify not keeping the old stuff as long as possible.

2.       Upgrading to smarter tools with new cool features will only benefit the one or two geeks on the team unless you take steps to train people on the new capabilities. Is that included in the business case?

Automating process

This is what business systems are really all about. The database replaced the card index and made it possible to share that information with colleagues globally, to search on fuzzy logic and to send a message at a single mouse click.  This was a pretty easy decision on hindsight and the business case is obvious now, but at the time, ditherers and weak leaders continued with their card indexes until they saw their customers walking into their competitors arms.
Plenty of leaders continue in the same vein today and every new step forward in technology will have innovators, early adapters, last minute Harrys and hard luck stories.

Technology is not the enemy

Since records began, businesses have had to find ways to deliver better products or services, do it at lower costs and win and keep more customers. There’s a percentage at the top end of this battle and there’s a percentage on the way out, the rest are headed in one direction or the other .  Businesses that choose to close their eyes to the importance of technology in this struggle have already consigned themselves to the scrapheap.

Face facts and make the most of it
Success at harnessing technology requires understanding a few basic rules and working with people you can trust to deliver.

Strategic advantage or state-of-the-art

The first big differentiator between software systems is their status in your market segment.
If you are considering a system that you hope will bring you in line with the main players, then this is probably “state of the art”, though if you are a long way down the pecking order it may still be classed as “strategic advantage“.
E.G.  If you run a large business carrying out maintenance type work like Sky TV maintaining satellite dishes, you will have automated scheduling that plans the shortest routes and sends jobs directly to the engineers PDA or mobile.   This has cut operating costs by 25% on average for these businesses and is a fast maturing industry.   If you want to bid for sizeable projects then you won’t stand a chance of winning competitive bids unless you have this in place.  That’s “State of the art” IT.
If you run a local cleaning business with a few dozen teams in vans and you are growing and ambitious, you probably don’t have this systems yet and your direct competitors probably don’t, so to you it is still probably “Strategic advantage” IT. If you are serious about growing, guess what you will be planning now!

Not only will the ambitious smaller firms be scrambling to get this competitive advantage, but the guys at the top are already planning to push the bar up higher and guess what you will have to do when that happens!

There’s one fact that is simply unavoidable whether it thrills you or fills you with horror;
Competing and winning in business in the 21^st century is primarily about winning the technology battle.
 Where has all the money gone?
 About the author