Requirements engineering strategy can make or break your project .

Part one – What would you like sir
Part two – Requirements,tests, training, help files
Part three – Why no project exists in isolation-what should be done
Part four – Business rules, Process rules, Process, Data, different viewpoints
Part five – Testing requirements is not optional
Part six  -Requirements strategy can make or break your project

If you’ve been reading my blogs on the subject of requirements, you will no doubt appreciate the level of importance I place on getting requirements right and then testing them before committing yourself to a contract or a technical specification.
Just in case you are thinking that this is in some way anti agile, then nothing could be further from the truth. Please read my blog on agile requirements engineering for a discussion on this topic.

Let’s take this opportunity to recap on why we do requirements. The simple fact is that once a development team start work on creating a technical specification, the till begins to ring up with costs and every time you make a change after this point more costs are added. The closer you are to rollout when you make the change, the greater the extra cost will be and that time phased increase is exponential, therefore the first purpose of requirements engineering is to contain costs and eliminate or reduce slippages.

The second purpose is to make sure that the end product delivers value by meeting the needs of the business precisely in order to meet or exceed the benefits targets set in the business case.

Getting requirements right therefore, is absolutely critical if you are to contain costs and deliver value

Developing a requirements engineering strategy

Each organisation and each project are different and requires a tailor made strategy for getting the requirements right by recognising, exploiting and working with the capabilities of the organisation.

To do this successfully, you will need a few things:

  1. A detailed analysis of the stakeholders involved in the as-is process in order to make interviewing efficient and thorough.
  2. A strong feel for the past experiences of the organisation in terms of successes or failures with software projects in terms of meeting business need and staying within budget and time constraints. This along with some tactful exploration of causes will give a strong steer about the current capabilities of the organisation to engage with a formal requirements process and to take seriously concepts like change control.
  3. A feel for the organisations ability to take on and successfully adapt change will help you decide whether and how far you might decide to upgrade their skills and attitudes to requirement engineering
  4. A good indicative plan that indicates the products to be created, their acceptance criteria, time scales for delivery and the amount of effort that will be needed from stakeholders.
  5. The understanding, agreement and total buy-in of key stakeholders to the proposed approach with full support in terms of making people and facilities available for the process

 

Stakeholder analysis for requirement engineering

Step one

Using RACI to identify stakeholders for the Requirements function.

In my blogs on business case techniques and models I discussed the importance involving the right stakeholders to gain buy-in and get a real picture of what success will look like.
In order to design the system, you will need a different type of stakeholder list, one that describes roles, responsibilities skills and communication. This list will give a clear view of where the knowledge skills and the responsibilities lie within the organisation and therefore point you at the right people to describe requirements and take responsibility for their quality. My favourite tool for achieving this is a well known HR instrument known as the RACI chart. Responsibilities Accountabilities, Consults, Informs and it provides a two dimensional view of a team that helps you quickly analyse the team for adequate skills, supervision, communication and quality control. It can be adjusted in form or emphasis to suit your precise needs, but the fundamental principal serves well in any circumstance straight out of the box.
Here’s an example;

RAACI example

The table above lists nominal roles across the top and Activities down the left, each cell is then marked with one or more of RACI to show who has what role in that activity.
The example is for a software development team, but if you were building a hospital it would list things like planner, builder, architect and activities like approve plans, complete design, etc.

A software project for a builders might involve, Construction director, surveyor, cost controller, quality controller etc and Liaise with clients, agree costs, sign off completion, etc.
Apart from being a huge benefit in helping to highlight the important stakeholders for your requirements process, the RACI chart also provides a quick but effective sanity check to make sure that your team is adequate and that there no duplications, conflicts or gaps.

Horizontal analysis of each task will quickly tell you whether there are sufficient doers and accountability exists and is in the right place.
Vertical analysis of roles will quickly highlight overworked, underworked, misplaced authority or responsibility and lack of or too much consultation and information.
Too much consultation stifles decision making and too little leads to dangerous decisions. Corporate culture can lead to busy bodies who don’t always follow through, or teflon in-trays. All of these issues need to be understood and ideally addressed ahead of system design, because the system will only perform as well as the people who use it.

Once you have created this chart, the next thing is to create a list of names with contact information to place in each of the role areas. If the project is large and/or complex, there may be more than one name in each box and there may be further sifting to do in order to resolve any doubts.
Don’t be surprised to find skeletons in the cupboard and lack of agreement over who does what. If you uncover these issues, now is the time to discuss them at a high level and attempt to get them resolved ahead of requirement gathering.

Step Two
The second step is identify the Actors, the people and systems that carry out tasks as part of this process and the sources of all the skills, knowledge and decisions required to complete the process successfully. This will generally begin with the R people in your RACI chart and will usually expand to people who do the work with or for the R person. E.G. the R may be in your chart as the Technical architects for design, but on investigation, you may find a DBA, a SysAdmin and many others who play key roles and these people also need to be interviewed.
The actual actors may be more usefully broken down to specific skill sets or disciplines as opposed to specific roles. E.G you may have Document writer, Interviewer, modeller all of which are actors within the BA function. This approach gives a slightly more abstract approach that lends itself to reorganising roles for efficiencies, or to adapt to a new system.Never be tempted to accept the assurance that a supervisor can tell you the whole story and you don’t need to talk to her/his charges. If anything this should be seen with an element of suspicion and tactful verification is a good idea.

To better understand and communicate how the various roles influence the outcome of a process, it is sometimes useful to create a fishbone chart adapted slightly for the purpose. Here is how i like to create it:

Stakeholder fishbone chart

The fishbone can be made as complex as you need it to be in order to show all the influences on your new project. The thing that becomes apparent very quickly is that whether they are aware of it or not, most of your stakeholders rely on others for skills, support, knowhow, data, administration and other inputs that can potentially prevent the processes progressing and hence you need to know about it and to resolve, or risk manage it.
Your fishbone chart will immediately tell you who to talk to and by way of a bonus, it will very quickly highlight the areas of influence, both positive and negative when it comes to rolling out.

Organisational culture and requirements process maturity.

Once your target interviewees are lined up, your next step is to hold a number of short interviews and/or an interactive workshop to discuss past projects, how they went and how the organisation reacted at the time and now. Asking them what they felt went well and what went wrong will go a long way towards gauging what will go down well, or will meet with resistance in terms of methodology.
The aim is not to deliver the perfect project, by your standards, but to deliver the best you can within the capabilities and expectation of the clients.

The last critical aspect of this phase is to get a good feel for their favoured mode of communication within this area. Do they have requirements documentation that they worked with in the past? Are they comfortable working with it? Does technical documentation create silos that exclude valuable stakeholders to the benefit of technical people .

This aspect is vital, because the quality of decisions they make and their perception of you as a trusted adviser will be directly proportionate to your skill in communicating the concepts clearly to them. Not only that, but your ability to get their attention at all let alone hold it long enough to achieve a useful level of consultation will depend on not confusing or alienating them with technical or complex instruments of communication or use of unfamiliar jargon.

A clearly communicated strategy and indicative plan

Once you have gathered your information it is time to make some preliminary decisions about how to take it forward. How to collect information, how to verify your information and how to communicate back to stakeholders ahead of defining the requirements.

Identifying these tasks, the stakeholder and support staff needed and the order and dependencies of the work, it is time to add this to a simple Gantt chart that defines high level activities, high level milestones and products to be delivered.

Understanding, agreement and total buy-in.

If you have done your homework and worked in a consultative manner you will be very confident before presenting the plan, that it will be understood and supported and will be accepted by your stakeholders.
You should present:

  1. An introductory explanation of the approach with reasoning
  2. A list of products you propose to produce backed by a simple concise explanation of how and why and samples.
  3. A Gantt describing the timeframes and milestones.
  4. A simple, high level risk assessment
  5. An indication of the time commitments required of key stakeholders.

At the end of this you should answer questions and ask for their full support backed by a sign-off of the plan.

Ed Taaffe is a senior Consultant in Business Improvement through technology and Hi-tech Product management.

Reblog this post [with Zemanta]

Part one – What would you like sir
Part two – Requirements,tests, training, help files
Part three – Why no project exists onin isolation-whwat should be done
Part four – Business rules, Process rules, Process, Data, different viewpoints
Part five – Testing requirements is not optional
Part six  -Requirements strategy can make or break your project

What would you like sir?

Countless reports on the reasons for project failures in the software industry point heavily towards poor requirements as a source of the problem. It isn’t too hard to see why that might be. After all if you hope to get exactly what you want, you are going to have to spell it out in some detail.

How many times have all of us left a restaurant disappointed because we misinterpreted what a dish consisted of, or had a bad experience ?

Ordering what you want in a restaurant where they speak your language is relatively low risk. There is a risk of misinterpretation and there is a risk of a poorly executed dish, a meal that arrives after a very long wait, or a nuisance at the next table making you uncomfortable.

If you want to give yourself a strong chance of being satisfied with your meal, first you will need to be aware of all these contributors and make your choices with this in mind.
Taking this approach might help you avoid the family from hell at the next table, the dish that isn’t what you expected etc and if it doesn’t work out you are at least in a strong position to seek recompense.

Software is much more complex than food and like a restaurant meal there are more concerns than simply  the ingredients. In an ideal world you would be dealing with a professional who could interpret your tastes, avoid the poorer restaurants and order on your behalf.
This is the main purpose of the Business analysis and product  development body of knowledge.

It gives you the option of working with trusted professionals that can help you achieve what you had hoped for and keep your costs down.

Product versus System.

Few people stop to consider the difference between developing products and developing systems for a private audience and will often approach both in exactly the same way, but although there is a lot in common, there are also critical differences.
1. The first and most important difference is the fact that a system will be rolled out to desktops ot devices and the organisation will train users and tell them to get on with it, whereas a product will be launched into a marketplace who have to be attracted to explore the product and then persuaded to purchase it.

  1. A system will largely be rolled out into a controlled technical environment whereas a product will be at the mercy every conceivable version of operating system and technical environment.

  2. A product must breakeven quickly, deliver a profit in the long tail and exit gracefully before it becomes a liability.

The first of these is one of the more telling differences for our purposes because it requires an entirely different approach to understanding requirements  and defining outcomes and it introduces a whole new level of financial constraints.

When developing a product, the Analyst/Product manager  is often working with a user advocate  or product forum to define the desired functionality and get requirements down on paper in the same way as with a system.

A better process will run Alpha and Beta releases with early adapters in order to learn about how users react to it and make critical changes that improve it’s chances. In an Agile world the Product Owner will release an MVP (Minimum Viable Product) and perhaps then an MMP (Marketable)
All the time the success or failure of a product rests on the likelihood of the user base receiving it will, perceiving a persuasive benefit and viewing it as value for money.
The project manager delivering a system on the other hand has the luxury of rolling out a system and only worrying about complaints that threaten it’s ability to deliver.

The project manager can learn a lot from the product manager in terms of delivering a well received output and maintaining good communications with stakeholders.

Innovation as opposed to state of the art

Projects that involve a level of innovation either in terms of process or the technology to drive it will require a different approach and a strong element of prototyping both as proof of concept and as a way of communicating to users a blue skies concept, will generally be the better approach leading to a point where requirements and scope can be nailed down and the process of delivering it can get under way.

Complex domain knowledge

Another situation requiring a different approach to requirements is the one that involves extreme complexity in a domain outside the scope of the analysts, project managers or technical staff.

Let’s say for example that we are building software to manage extremely complex trend analysis for  forex traders and only a small number of skilled individuals understand the underlying mathematics.

To get a product manger or analyst to a sufficient level of understanding could take years and it would still be a second best option. The best option is a totally agile approach whereby the statistician the analyst and the developer all sit together and build prototypes without the statistician ever needing to understand the underlying code and architecture, or the programmers and analyst ever understanding the fine detail of Monte Carlo analyses etc being used to construct models.
In this situation the requirements are written after the code has been written and unit tested and it’s purpose is to support maintenance and future development processes.

COTS versus Development

The biggest area of effort by a long shot is the purchase and implementation of COTS (Commercial Off The Shelf) software systems.

Right form early days in the industry, there was a realisation of the need for reuse of software and many of the various efforts that came and went have been sold to us on the basis of promoting re-use. In reality precious little is developed in Com or reusable classes and SOA is still not that widely used.
The theory that once you had created a “customer object” you didn’t ever need to do it again, just never caught on, but COTS systems did and today there is very little development of end to end systems outside of software houses that develop products.  Nobody builds their own CRM, or ERP, etc, because it makes no sense when you can buy it straight out of the box at a fraction of the cost. Bill Gates freely admits that he ran the business on SAP using his own products to integrate where he needed the extra flexibility.

The issues with COTS however are that businesses are all keen to differentiate their offerings and this adds to the variety of processes and business models in operation which in turn means that many of these all encompassing systems are a compromise rather than a solution and require a lot of integration and customisation in order to make them deliver benefits.

There has never been to my knowledge, any attention given to the needs of these systems. The most common problem I have encountered is people from the business assuming that you don’t need the normal skills to deal with this because it is in the box and it is like buying a lawnmower,  you bring it home and tell “the IT boys” to plug it in.

In reality this is a very dangerous mistake and pitfalls are as follows:

  • You are reading wooly,  warm and friendly descriptions of what the system will do, but no detail about how it gets there. All COTS is sold with a “Caveat Emptor” clause and unless somebody knows all the details of what it must do and whether it actually does, then you will end up with a very expensive system that just is not suitable.
  • The complexity and risk attached to integrating COTS systems with other systems can sometimes make them almost as expensive as starting form scratch.
  • The impact of the COTS systems on your infrastructure and on other critical systems can be devastating unless it is properly understood.

The job of procuring COTS software is  complex and tricky and it can often be a struggle to convince business stakeholders of the need for detailed requirements, detailed investigations, complex questionnaires, proofs of concept, and a range of testing before making the system live on a production environment.
The size and complexity of this area is such that it could not be addressed in this series, but suffice to say that all the rules about requirement apply equally and there are a number of new concerns to be addesses.

Requirements, tests, training, help files – the connection?

Part one What would you like sir

Part two Requirements,tests, training, help files

Part three Why no project exists onin isolation-whwat should be done

Part four Business rules, Process rules, Process, Data, different viewpoints

Part five Testing requirements is not optional

Part six Requirements strategy can make or break your project

 Really! – Have you seen this new stuff? 

This could easily have been Mick Jagger and Keith Richards after their first successful gig. In the modern world, it is more likely to be a hard working CTO talking to a COO about his systems needs.

Systems are not like any other purchase. You can go to a tailor today and he will do almost the identical things that a tailor did for Julius Ceaser.  You can call an architect and his approach will differ little from that of Hiram Abif apart from the time taken to produce drawings.  When it comes to systems though, it is more like medicine. Patients differ, you only hear what they tell you and you don’t really understand anything you have not personally experienced, you have to tease it out using your instinct and experience and play the numbers game.

There are techniques for flushing out the problems and verifying them and for getting the medicine accepted, but ultimately every doctor likes to deal with life threatening situations. If he succeeds for whatever reason, he’s a hero and if not, well, he did his best.
Apart from a lucky few, most of us in the software industry have to earn a living by delivering value in the real world through cost savings, or competitive advantage and that’s a tall order.
It calls for a mixture of calculated risk taking and good fall back positions and it requires an insight that combines real understanding of the business domain with leading edge technological ability. It doesn’t matter whether this is done by a committee or a genius as long as it gets done

The requirements challenge

So how do you meet a business person, listen to his/her needs and six, nine or thirty six months later get a well done, thank you response?

There isn’t a really good answer to this. If it is six months, you are in with a chance. If it is nine you are still in there, at thirty six, the likelihood is that before you deliver this, a much better solution will have been invented, or the problem will have been replaced by a new one.

There is a considerable number of methodologies out there, most of them geared up to coax you into paying for expensive training courses and few aimed at really bridging the divide between what a business needs and what technology can deliver with reasonable reliability.   A methodology that really works has to be able to understand business needs, translate it into process and match this with the best possible technical solution.

Defining the problem

This is not as simple as it sounds. If you read my business case blogs, you will probably remember the way I recommend tying corporate objectives in a direct and accountable way to the benefits delivered by the business case.  That makes perfect sense of course, because a good business sets a plan and then works to deliver on it.
There are other scenarios however that need to be taken into account, this example will hopefully help to illustrate the point.
Suppose we approach an Amazon tribe still living in the traditional way, tell them that we would like to give them some gifts and ask them about the problems they would most like to solve and the things that might give them the most satisfaction.  Problems and exciters. The likelihood is that having seen bright steel machetes amongst the crew, they might suggest a steel spear to make fishing more productive. We might then suggest that rather than give them a spear, we can give them a monofilament net. This way they can catch enough for the whole tribe in an hour instead of having to fish all day.Here we have seen a classic example of the two cardinal sins of analysis:

 1.       Asking a question that the object of the question can’t possibly be expected to answer well.

2.       Answering with a solution rather than a problem.

The interviewee in this example can’t be expected to know how to manage this process, so the entire responsibility lies with the interviewer. By the way, that includes the many occasions when the interviewee believes she knows exactly what she wants and is driving.
The responsibility of the analyst extends to making sure that the interviewee has explored and understood the problem and has a sufficient understanding of it and of the desired outcomes to start either designing or verifying the solution.
I include verifying here, because an increasing number of business people believe themselves to be tech wizards and arrive with fait accomplis and a budget wanting a technically trained fellow to make her vision happen.  In these cases, instead of designing a solution, the analyst goes through a process of verifying the problem, the requirements and the solution.  If these three don’t match and the sponsor doesn’t see it then it is up to the individual analyst’s conscience  and professional intergityas to what he/she should do next.

In Summary

In this part we have talked about three key issues:

1.       The unique challenge facing a systems professional in getting to the real problem before starting on the solution.

2.       Educating the client about possibilities in order to truly understand what the problem is.

3.       Tempering the part time inventor with a little pragmatism without dampening his/her enthusiasm.

The next part will get much deeper into the language and culture of requirements and and discuss different methods of achieving a reliable result.
 

 

 

 

Reblog this post [with Zemanta]

UAT – me, how do I do that?

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 ?

 

Reblog this post [with Zemanta]

Why the SMB/SME holds all the aces when it comes to IT

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

 

 

 

IT investment for the small businessman and novice.

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 21st century is primarily about winning the technology battle.
 Where has all the money gone?
 About the author

  

 

 

 

 

 

  

 

 

 

 

 

Delivering benefits is no longer about getting a system signed off

(Who’s minding the shop?)
This blog is an attempt to stimulate discussion and understanding of the balance of responsibility for delivering business benefits from IT investment.
It is now fairly widely recognised that this is not as simple as choosing a system, getting it working and reaping the benefits, but as yet we can call on very few examples of good practice in making it work.
The business argument.
We have no time for discussions about how it all works, we just want a business case and if it gives us the ROI we need with acceptable risks, we want to do it. At least that’s the CFO’s line. In reality, many of these projects begin life as pet projects of the CEO, or other senior manager and it is clear from the outset that the question is not will it work, but make it work.
This is largely an understandable attitude, because businesses must be directed and managers must manage and sometimes the outcome can be a life or death one.
The IT supplier argument.
Be the supplier an in house department or an external supplier, the situation is not hugely different. The supplier tends to confine their responsibilities and activities to making the technology work. Better suppliers provide advice and guidance on rollout, but that is the limit of the activity and there is no responsibility beyond meeting technical requirements. This is wholly understandable, because the supplier has no control over whether the business case was correctly put together, whether the requirements were detailed enough or whether the culture is sufficiently flexible or disciplined to make the new system work and deliver benefits.
So who‘s minding the shop?
Well the answer very often is that nobody is minding the shop. Rarely is anybody in the business equipped to do this job and the suppliers are not getting involved.
The most usual scenario is that the system is delivered and there are issues and misfits that become immediately apparent, then there’s a return to the drawing board and changes are made and a re-launch and things are much better. Often you’ll find a new project with a new name the following year, billed as an upgrade and it finally knocks the thing into shape. Two years late and dramatically over budget the project is complete and nobody ever asks whether it delivered benefits because at this point the busines is bus with a whole new set of issues.
The other common scenario is that a consultant is hired to manage the project, he/she is expected to have a project management qualification PMI/Prince etc and have handled one of these type of projects before, maybe even in this industry.
Often the contract is already in place, the product defined and dates and budgets set.
Where does a Consultant go from here?
1. Recommend someone else who needs a bit of experience.
2. Take it on and hope for the best
3. Challenge the client at interview and get passed over as wrong attitude
4. Take it on and then challenge the client later via a robust consulting methodology
5. Challenge the client at interview via a robust consulting methodology
6. Offer to challenge the project’s soundness for a reasonable fee and provide a dispassionate report.

Testing requirements is not optional

Part one – What would you like sir
Part two – Requirements,tests, training, help files
Part three – Why no project exists onin isolation-whwat should be done
Part four – Business rules, Process rules, Process, Data, different viewpoints
Part five – Testing requirements is not optional
Part six  -Requirements strategy can make or break your project

Yes you read it right. If you are one of those people who believes that testing begins when the supplier drops the system in your lap, then you have missed the point entirely. Testing starts when you build a business case and you test it to make sure that the solution is feasible and the figures are sound etc.
The next important test comes when the requirements are deemed to be complete.
Here’s the summary of a good requirements definition. Depending on the size of the project this could be one document or one per viewpoint. The thing that is important is that the right problems have been addressed and the problems have been identified and described clearly to the suppliers or developers in a way that makes it easy for them to get it right first time.

Business case — Tested via a Business case review, or Stage gate review.
User requirements – Tested via user and stakeholder review. (The problem)
Functional requirements – Describe the functionality that the system will provide in order to meet user requirements. (The solution)
Non Functional requirements – Describe all the constraints like speed of operation, reliability etc.
Data requirements – Describe in detail the inputs and outputs of the system and cover both the validation of human input and the specification of machine interfaces
Business Process – Describe the time phased rules that govern how the business goes about achieving it’s goal with the system. 

Business case review

Has the scope expanded, or the costs changed, or has the timeline been impacted in such a way to negatively impact the business case.
Has the level of complexity shed any doubt on the organisation’s ability to deliver.
Does the bsuiness case still stack up

Business process review

  • Do the processes join up to deliver a result
  • Does each process receive the required inputs
  • Do they handle all exceptions sufficiently
  • Are processes efficient
  • Will new processes deliver the expected benefits
  • Are the risks managed
  • Are the assumptions sound

User requirement review

  • The aim is to discover problems like ambiguous requirements, missing requirements, inconsistent requirements
  • Check against process models to ensure that nothing has been missed.
  • Check against the ten commandments

Functional requirement review

  • Traceability to user requirements
  • Design agnostic
  • Achievable
  • Complete

Non functional requirement review

  • Measurable
  • Explainable
  • Traceable to a business requirement

Data requirements review

  • Complete
  • Clear definition of types, mandatory fields, sizes,

Prioritisation of functional requirements

Armed with best guess estimates of time, cost, risk and benefits propritise them a number scale ar a scale like MoSCoW

Reblog this post [with Zemanta]

Fifteen common sense cost cutting ideas

View of Wall Street, Manhattan.

Image via Wikipedia

  With a forecast of rising inflation putting pressure on costs coupled with shrinking sales in certain industries,  then many businesses will be paying  extra  attention to cost cutting opportunities. In this blog I have identified the top 15 generic opportunities for cost savings that can be applied either directly or in a modified state to almost any business.

Cost cutting should be viewed in a positive light

Done correctly, the benefits of a cost cutting exercise can deliver more than just excellent immediate financial returns. It can also be a vehicle for consolidation of management process and shedding of wastage after a long period of growth, when there may not always have been time to prune and shape the expansion for maximum value.

Each industry will have it’s own specific cost areas that are high on the agenda, but there is also a great deal that is shared across business in all industries.

Fundamental rules for cost cutting exercises

The first rule of finding good opportunities is to look in the most likely places. Natural human weaknesses are a dead cert; poor communication, empire building, hanging on to bad routines, loss of direction and purpose, poor decision making, fear of hiring good people, fear of encouraging good people.

The second rule of finding cost cutting opportunities is to avoid the ones that reduce the value proposition to your customers, the ones that harm communication, especially with the customer and the ones that rely on volatile currency rates or political situations and ones that de-motivate key personnel.

Below is a first stab at creating a universally applicable list of good cost cutting ideas:

1.       Reduce the size of HR and bring most of the hiring procedures inside business units. Let outgoing good people choose replacements and failing that let colleagues do it.
Every person they introduce will save an agency fee, the communications loop is cut to a fraction saving wasted time and effort and the new person will fit the job perfectly and blend in well.

2.       Offer bonuses to all staff and ex staff to help you fill vacancies, not only will you get better people you will save a fortune in agency fees.

3.       Get rid of the call centre and make each account manager responsible for maintaining the relationship with customers, if not directly then directly supervised. Task them to up sell and cross sell at every opportunity and to discover product opportunities and to get on first name terms.  Not only will your turn a liability into an asset through more sales, you will strengthen customer retention and be better informed about new product opportunities.  Every time you solve a problem for your customer, even if your product created it, you are strengthening the brand and deepening the relationship, provided you handle it well.

4.       Share your marketing costs through joint campaigns. Partner with non competitive  and complimentary businesses in your industry to share the cost of your mailings and other marketing initiatives. As well as sharing the cost of the campaign, you may also gain access to their database.

5.       Stop posting letters and use email for everything. It sounds simple, but the mail vans are still delivering sacks full of messages days later at substantial expense when they could have been delivered instantly and for free.

6.       Clamp down on meetings. By this I don’t mean stop them or give them a stigma, they are vital. Make sure they are used correctly and only when needed. Make sure there is an agenda and minutes and they are chaired.  Consider training or coaching prople or even having a meetings baron who chairs all the important ones and supervises the rest.
Make sure that people who work together sit together.

7.       Make sure everyone can type with more than two fingers and has been trained in advanced usage of the basic productivity software packages to get the best out of them. Like email, it sounds like a no-brainer, but the world is full of people who have struggled for years at 50% capacity all for the want of half a day in the classroom.

8.       Install VOIP and use it. If you want to try it out first, you can put Skype on every pc and cut out all costs attached to internal voice communications, this costs nothing, just an email explaining to the staff how to download and use it.
A well chosen VOIP system can also dramatically reduce all of your messaging costs for a moderate initial investment.  This is a must have, just like email.

9.       Negotiate tighter costs on your big purchases, if your market shrinks, your suppliers will shrink too. Give them a chance to secure your business and gain some extra discounts from them.

10.   Combat wage demands by making the staff happier at work so they don’t want to consider leaving. Encourage the people who are gifted in this way to organise sport and recreation groups. Provide child care for pre-school children and after school care to keep young mums at their desks and happy. Organise bulk buying clubs and help your employees to reduce their costs by buying the regular stuff at wholesale prices.

11.   Encourage all your people to work from home at least one day a week, this will reduce their motoring costs by 20% and hence their cost of living by  as much as 5%. It will also motivate them and help to retain them.

12.   Train your managers to show appreciation regularly, Ideally do it by example. This can substantially  mitigate pay demands.

13.   When you need new software consider the open source option first. With the right advice you can discover a great deal of very high quality software with no licensing costs and low initial costs and support costs.

14.   If you develop software hire a good agile project manager to deliver the low hanging fruit quickly and bring benefits in early, this will dramatically improve the business case.

15.   When you make changes, don’t just assume they will work, get away from your desk and make sure they are working.

 

Reblog this post [with Zemanta]

When is a business case not a business case (part 4)

 Read part one  Read part two Read part three  Read part four

In our previous instalments we discussed the preparation of a business case and calculation of the data needed to prove it.

Today we will be discussing the art of delivering the business case in such a way that it competes on a level playing field with all other initiatives currently on the agenda.

There a re a few fundamental rules to bear in mind when presenting any proposition:

1.       Recognise and understand your audience so that you can directly target a known need or desire with your proposition.

2.       Use the appropriate language and context to present your proposition.

3.       Get your timing right.

4.       Demonstrate understanding of and sensitivity to the operating environment.

 The first paragraph should always be entitled ‘Executive Summary’, but it should be the last one written.

The next paragraph should be a backgrounder that demonstrates succinctly and understanding of the operating environment, I.E. political, environmental, social, technological.  Make sure you don’t fall into the trap of contradicting the CEO. Work form the five year plan or current year plan or what ever is the most relevant document and if there have been significant changes in the operating environment since it was written then discuss it with senior people so that you reflect it accurately and delicately.
You may find for example that the CEO published a plan for robust growth ina bullish market three years ago and the CFO is now investing inwardly in cost avoidance projects while they watch the news with interest for an indication of the way forward.

In this case you need to be able to reflect this in your businss case so that it sets the scene for your cost reduction proposal.
 When it comes to writing down your propositions, bear in mind that there will be two distinct audiences, those who want to scrutinise the details and those who want the bottom line only.
The latter type will very often be relying on the former to take care for the detail for them so it is very important that you address each in the appropriate manner, presentation and language.
In part two we drew a map that linked features to benefits. In this section we will expand this idea further and we will map those benefits to stakeholder driven propositions.

Here is a simple example from my own experience.

Strategy and KPI mapping

 Strategy and KPI mapping

 In the diagram above we can clearly see that the CEO has published a key goal for the current period which is to improve net profit margins by 1 %.
 The CFO has a related KPI called indirect costs/sales volume and he is hell bent on improving this KPI by 1 point in order to meet the CEOs  goal.
The Operations Director is working on a goal to reduce the paperwork element  involved in picking, packing and shipping products, while maintaining or improving delivery success rates

In your business case the value propositions would address each of these stakeholders in his/her own terms and use context to draw an accurate picture of the scale of benefits.
E.G.
The proposed system will positively increase net profit margins by a factor between .2 and .4% in it’s first year of operation and reach breakeven in the first quarter of year 2.

In achieving this, it will increase the costs/sales volume KPI by a factor of around .3 through virtually eliminating the paperwork involved in the picking, packing and shipping aspect of operations.
Additional benefits will be reduced propensity for error in this area that we have not attempted to quantify.
For detailed breakdown, see the financial analysis section.
You will note that this sentence describes the system in terms of benefits that can be readily understood and appreciated by each individual stakeholder.
By quoting KPIs the scale of the benefit is immediately put into context so that you capture the attention of your target readers.

Presenting the figures.
You don’t need to be a financial analyst to figure out that bringing in benefits early has a dramatic affect on the financial results of your project.  If you cast your mind back to part three when we talked about Net Present Value (NPV), you will realise that bringing in, or saving  a million next year rather than the following year, supposing a discount rate of 10% will deliver an extra 100,000 in benefits.  Not only that but it reduces the total investment required, thus improving ROI and freeing up capital for other important projects.

This simple exercise will help you optimise your business case by bringing forward benefits where it can be done.  You may remember that in part one we talked about listing the features and benefits that make up your projects and creating metrics for each feature.
Here is a simple tool we use to prioritise these features.

Tool helps with prioritising features

 If you need to analyse more complex and more data rich cases, then a Pareto chart can be an excellent way to single out the low hanging fruit.
For non financially aware people you may be able to put the benefits in context by taking the ROI and calculating how much extra revenue it would take in order for the business to deliver that same return through extra revenue generation.
In order to make this case rock solid you need to also present at least one potential alternative tactical solution and a do nothing scenario.
In your final analysis, you will compare the do nothing scenario, the tactical solution and the proposed solution and demonstrate clearly the basis for your proposal. 

Project plan
An indicative project plan should be included in order to demonstrate the likely timelines including benefits realisation activities, implications for personnel, budget and  team structure.

The executive summary.
In this section we always place two things:
1.       Our proposal, stated in direct no nonsense language aimed at all relevant stakeholders jsut as we discussed earlier.

2.       Our paragraph of analysis that briefly describes the alternatives and the rationale behind our proposal.

The executive summary should contain nothing but the bare facts and concise value propositions, no rambling intros or winding up paragraphs. It is a business document and it is about cold hard cash so keep it clean and factual and get straight to the point.

Sign off sheet
Don’t forget a sign-off sheet so that they are very clear of the immediacy and urgency and the fact they will be expected to make decisions as opposed to having a discussion.
Presentation

n order to present the business case, our strong recommendation is that you produce three artefacts.

1.       The full business case

2.       A one page summary including the executive summary  and financial conclusions

3.       A presentation of four or five slides demonstrating pictorially, the background, the benefits, the financial analysis, the project outline.

The first  communication should be the short summary sent by email to the stakeholder list along with an invite to discuss it in a formal setting.
The second communication should be a presentation of the business case with opportunities for questions and answers and the full business case handed out about half way through the presentation once the key points have been presented.

  Read part one  Read part two Read part three  Read part four

 

Reblog this post [with Zemanta]