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.

Negotiation skills for project managers

 

An absolutely key skill that no project manager can go out without is basic negotiation skills.
From achieving consensus among stakeholders to getting the right procurement contract and managing exceptions, the one thing you absolutely MUST HAVE is the ability to negotiate effectively.

Here’s a few golden rules to help you negotiate more effectively whatever your position may be:

  • 1. Always aim to start and end your negotiation procedure on a high note. Be positive going in and be positive when you walk away from it, whether it is an adjournment for another day or the final handshake time. What I mean by leaving on a high note is that everyone should feel that they have achieved something, even if they worked hard for it and that they could comfortably return to do business with you again.
  • 2. Create a terms of reference at the outset. This will often be a fairly low key statement that frames the negotiations as opposed to a formal written invitation, but one way or another it is important that everyone knows what is at stake and why they are doing it.
  • 3. Decide in advance what your walk away scenario is, and what you want out of it and make sure the negotiating team are all clear on this. Place nobody on the team who might have any reservations about your goals.
  • 4. Research the other side and gather every scrap of useful information that might help you to understand their goals and to predict their walk away positions.
  • 5. Decide your beginning position and bear in mind that this will have a substantial impact on the outcome. E.G. In a sale negotiation it is proven that the higher price at which you begin the higher price you will reach agreement at. It is also useful to recognise that too high a starting point may prevent the negotiations beginning.
  • 6. If possible retain a refer to authority that allows you to take time out before deciding.
  • 7. Drink water twenty minutes before beginning, it is believed to make you concentrate better.
  • 8. Listen attentively to the other side, question every point and every request until it is crystal clear before making any attempt to respond to it.
  • 9. If you reach a situation at any point where you are not able to get agreement, set that point aside to return to later and move on with matters that are easier to agree.
  • a. Return to the set aside points when the negotiations are in a positive mood after a number of easy agreements and a lot of progress has been made, it should be easier then to reach agreement.
  • 10. Aim to reach a final situation where both sides feel that have won. If you can’t do that then keep on negotiating till you reach a position that fits your starting criteria.
  • 11. Be wary of making it personal, stick to your stated goals and avoid being baited, or finding yourself in competition with other individuals, it’s all about reaching an acceptable agreement.

 

Reblog this post [with Zemanta]

Project kickoff – don’t miss an opportunity

The project concept has outgrown it’s initial purpose to become pervasive in all areas of business and government.
This blog is relevant to all projects, but especially to those traditional ones that are created with a new team to deliver a specific project outcome such as a business change.

The challenges faced by Projects

The challenges faced by Projects are immense and not srprisingly, they represent the same issues that lead to the inception of the project as a model, namely:

  1. The shop must stay open while the improvements are made.  I.E. key people can’t desert their posts, so someone needs to come in to lead it.
  2. The project has to have the ability to make decisions and move forward independently if it’s not to grind to a halt..
  3. It must have its own clear structure of reports, responsibilities and consults, separate from the organisation.
  4. It must overcome the tricky and time consuming challenge of forming a new team and getting it up to peak production.
  5. It must coordinate and arbitrate different egos and personalities to work in a new structure.
    It must communicate effectively as an entity
  6. It must deal effectively with sometimes fraught corporate change environments
  7. In order to achieve even a pass mark in these seven key areas, it is vital that a project team is built and structured to support these functions and that the structure is strong, well designed and policed sufficiently until it is functioning efficiently.

If you are not in the habit of producing and agreeing a project structure document up front, then embracing this simple idea will move your project management performance up to a whole new level.
if you are able to go the next level you will not only end up with a sold structure that is sufficient and functional, you will make sure that the right roles are created, the right people are chosen for each role and the new team is quickly marched through the complex process of Forming, Norming, Storming and Reforming.

Project kick-off is almost indispensible

if you have been following my series on Project management, you will no doubt be aware that we place considerable importance on setting up the project correctly with the right structure and the right people. 
The last and very important lap in kicking off a high performance project is team building.


 When I started in this field in Ireland 20 years ago, we had a uniquely Celtic way of doing the job. we took everyone away for a working weekend in a great hotel, We did a two hour stint on Saturday and the rest, the important bit was drinking too much revealing too much about yourself, making friends and building relationships.  Today we hire coaches to set up special activities that are more politically correct and if they are good, they achieve the same things.

Get their attention

I am a great believer in taking the team off site for a few days. Left onsite people will continue to do the day job and they will not engage with your project or your team.
The people who want to remain aloof are the very ones you most need to keep focused and to do this you need to remove all their other toys long enough to get through to them.

Get them interested

A vectorized image of project dimensions.

Image via Wikipedia

The second thing you need t do is to demonstrate to them the business case for your project and have a business sponsor make it very clear to everyone just how important the project is to him/her. This last bit is so important I am almost tempted to repeat it. If you don’t get strong verbal and moral support from the business, you may as well throw your hat at it right now.
The third thing you need to do is to paint a little detail around the vision and make more real or concrete. To do this you need to find ways of demonstrating what wil be different when the project has been completed and how it will effect each of the stakeholders present and the organisation in general. This is ideally an expansion of the business case put forward earlier, but with more detail to fill in the how rather than just the why. Models, diagrams, prototypes and individual contributions form affected stakeholder are all effective tools for bringing the vision to life.

Get them involved

 Project Management Plan

The fourth thing you need to achieve is to make it personal for each member of the team. It is all too easy to play around with concepts and pass comments on them without ever considering them as reality. Like furniture ordered from the internet, It is only when the postman delivers it that you are forced to unpack it and start considering where it will sit i your life and how you will live with it. This is the time you want your people to consider these issues so that when you call on them to do their bit, they are able and willing to deliver.
A simple and effective technique to help with achieving this is to hold joint planning sessions with the entire team whereby they nominate the high level tasks, point out dependencies  and highlight the risks,  issues and assumptions.
It doesn’t matter if you already have a plan that you think is great, I would strongly recommend binning that plan and starting again because of the extra value you can get from this process.
Joint planning is the first time the team work together and it is the first demonstration of who knows what, who does what and where the tensions may exist.
After the first session you can visit individuals and discuss the issues if you feel that things need to change a little in order to keep the peace.
In addition to territorial issues, the process also forces people to consider these commitments alongside of their existing ones and to consider the amount of time and effort required of them and surface any conflicts early on.
The last element of joint planning, but by no means the least, is to discover the areas where the team members depend on each other for knowledge support or assistance of any kind and begin to break down the barriers and start off this process of team building.

Define some real actions

If you are to reap the true benefits of the work you have done so far, you simply MUST get positive proof of your success by way of actions accepted and completed by the team. These actions will deliver preliminary products of almost any nature, but what they will do is
a). They will set the scene for accepting and completing actions on time
b). The actions will be chosen to involve small groups and pairings that begin the process of forming partnerships within the team.

The outcomes of a project kick-off meeting

  • A strong sense of common purpose built on a clear shared vision and sound communication and sponsorship.
  • A well defined and understood project structure that has been explored and proved itself viable.
  • A clear vision of the work to be done the issues and risks and the critical success factors.
  • A high level plan that is commonly owned and understood along with risk, issue and assumptions logs.
  • Initial tasks completed and a team that are comfortable to work together towards the common goal
     
Reblog this post [with Zemanta]

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]

Why no project should exist in isolation and what needs to be done

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

How requirements language can contribute to the solution

The very thing that brought about the project as a business entity can also be it’s worst enemy, especially when it comes to technology. The project isolates the goal from the rest of the business by providing it’s own governance and budget and treating like a mini company with a project board in place of the board and a Project manager in place of the CEO. The stakeholders take the role of shareholders and the sponsor that of Chairman.
Project structure is necessary in order to get important tasks completed quickly without having to fall in line with all of the political and process barriers that would otherwise smother it. The problem however is that this isolation often leads to forgetting to ask simple sensible questions like ; “Do we have something already that can do this?”.

I once was engaged by a large public sector organisation to look for a solution to their string of failed web projects. In the course of initial investigations I discovered that they had no less than 6 content management systems any one of which could have provided for all 100 plus websites that they managed. Each project had been considered in isolation and nobody had considered whether more software was needed.

How requirements language could have solved this problem.

The reason things happened the way they did is that nobody said “We need to deliver our messages 24/7 on demand”.
Nobody said “We need a way to encourage feedback from our audience” etc etc.

Nobody said “we need John to be able to publish stuff instantly and get it reviewed and in front of our customers within 30 minutes”.
The reason nobody said these things is because nobody asked them, or at least nobody asked them the right questions, or asked them in the right way.

Here’s how it works best.

The Business person says: “ I need to influence the market to purchase more of our products”
Here we have a business requirement/business problem/probortunity. The terms you choose depend on your viewpoint. In this example it could any of the three. The key is that this is the goal which kicks off the business case and which is ultimately measured in the KPIs you define for benefits realisation.

The Business Analyst then adds some deeper definition like ballpark estimates at timescales, size of increase and other key constraints.

The Business Analyst then speaks with Marketing people who tell him:

“We need to reach these segments.
We need to deliver these messages, we need to make these things available at these points in the buying cycle on a 24/7 basis.
We need to encourage them to approach us in these ways.”

Business analyst then brainstorms with technical people, designers marketers and everyone with a stake and they decide on a high level plan of how this goal can best be achieved.

At this point we have high level requirements. I prefer to refer to them as high level process requirements just in case anyone starts designing systems yet, but they have not developed beyond business requirements and are dealing with “how” rather than with “what” we want to achieve.

The Business analyst then draws use cases from these requirements that provide some detail on the everyday activities of users and the systems they need in order to support them. He/she does this iteratively, continuously checking back with business stakeholders until he/she has a clear understanding of everyone’s role and what they will need to achieve/do (use cases) in order to deliver on the high level requirements.

The Business analyst gathers high level costs and timescales and organises a scoping session when the team make a first draft at deciding how much of this they can afford and which bits will give the best returns for lowest risk.

Verifying the detail behind the more complex use cases is beyond the scope of this blog, yet it is critical to at least acknowledge that this verification must be done to bring time, place, and sequence to these simple use cases and to get an understanding of the processes required and how they differ from, or add to, those which exist and equally importantly, how they can reuse existing processes.

At this point the business analyst converts the use cases, business rules, models and scribbles into a formal set of requirements written down in a straightforward requirements language and taking great care not to define the solution at this point, simply to define the requirements so that a technical team can decide how best to meet these requirements technically, while taking into account the tools they already have.

The rules for writing good requirements

Below is a simple list of 10 rules that you can use to test your requirements once you have written them.

Value – Traces directly back to a business requirement in the business case, i.e. it adds value
Clarity – Give it some thought, be aware of your audience and don’t use three words where two will get the job done. Above all don’t use jargon including company jargon and if it is absolutely necessary to use technical terms add an explanatory footnote.
Design Free – This is by far the most important rule. Don’t even hint at the design. Stick strictly to outcomes. How it is delivered is down to the specification.
Achievable – There’s no point in asking for things that can’t be done technically, are beyond the budget, or are not going to be accepted in the user culture. This last part has been the downfall of many CRM implementations. If the culture is not ready, then don’t do it yet.
Complete – The requirement must give the reader sufficient information to work form the document without your standing beside him/her.
Consistent – Language and style always depends on individuals, the most critical thing is to be consistent so that the reader can learn your style and be confident in understanding your meanings.
Unambiguous– Don’t be woolly and don’t be coward. Spell it out clearly. Words like nice, fast good have no place in requirements. Define what will be nice or fast or good and make it measurable.
Verifiable – Assume that you will also have to write the test cases and test scripts and ask yourself how you will test this requirement. If the requirement doesn’t give enough information for this , then it is not verifiable and not complete.
Atomic – Take your requirement down to the smallest unit you can. Always ask, could this be broken into two requirements. If the answer is yes, do it.
User experience – This one applies mostly to products, but increasingly it is important in business change scenarios. Ultimately your user will feel an emotion or reaction when using your product. This the ultimate test for your product, the one where it wins or loses. This is where you describe the reaction you are trying to produce.

The last and very important step in requirements definition

Now that you have a requirements list, and assuming that all the context of this project has been communicated to the recipient of your list, the next step is to take this list to your supplier.

Regardless of whether the supplier sits at the next desk or is Microsoft Corporation, the same rules apply.

Add an extra 5 empty columns to your requirements list with the following headings: OTB (Out of the box), CON (Configurable), CU (Customisation required) New (New feature needed) note (Here they enter the number of any footnote they need to include.

My personal preference is to ask for ballpark time, cost and risk estimates alongside of any new code or customisations

This simple exercise will give you an immediate heads up on how much new code, new systems and other effort, risk and expense will be involved and it will take you one step closer to defining the final scope of your project and/or choosing the best supplier.

Today we talked about the issues of language and viewpoint when setting out to define system requirements and we defined the Ten Commandments of writing good requirements.

We did however gloss over a very complex and important area in terms of exploring, defining and verifying process, rules and business rules in order to write requirements that you can feel confident about.

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]

Planning and comunication is the root of management stress

How long will it take?

Let’s start with scheduling. How long do you think it takes your average employee to handle email, chat to his/her colleagues, dip out for cigarettes, have lunch, wind up in the morning and wind down at night? 2 hours, 3 hours, 4 hours, 5 hours? Are you sure you want to know?

 I suggest you monitor this for your own purposes over a period of about a week.

Now have you allowed for the long drawn out meetings and the important ones called by you and have you allowed for timesheets and project meetings and the team meetings? And of course the stream of emails.

Are you sure you have not missed anything?

Be honest with yourself, how far out was your first stab at this in terms of percentages?

Privately, you should perhaps consider what your estimate might have been, had you not been primed for it by this blog.

Now ask yourself what effect this minor oversight might have had on a project involving ten people for nine months.

Are you feeling the stress already?

Are the stakeholders behind you?

OK, so we started at the easy end. Now let’s up the stakes a little.

Do you know who all your stakeholders are?

Are you confident that a new stakeholder won’t appear out of the woodwork and bring it all to a halt unexpectedly?

So you have a comprehensive list, are you absolutely certain that every one of them knows exactly what you are planning to do and what the impact will be for them.

Ok so you circulated an email. Can you be absolutely certain that they read it?

Be honest, you know they didn’t, now ask yourself this; do any of these people have the power to stop you, officially or not, if they decide that they don’t like what you are delivering?

We both know the answer to this and we both know that even if you had extracted signatures on paper documents it would not really make much difference. By now you probably don’t want to go to work tomorrow and frankly I don’t blame you.


Are your team with you on this?

So we have covered some very important ground, but there’s still some way to go. It may have crossed your mind that if you planned this project on a poor basis and you tasked ambitious, hardworking people with targets, which we now know are impossible, they are probably already struggling and keeping it from you.

Ask yourself this; what will have to happen before a team member lets me know that there is a problem? Will you still be in a position to resolve the issue at that point?

Ask yourself this; how much easier would it be if you had scouts out there watching out for potential problems and warning you

in advance of the risks so you could be prepared?

Are you sure everyone is expecting the same outcome form this?

Finally let me throw the big one at you. How will you know you are finished?

What will success look like?
Will your stakeholders know whether you have succeeded or not? 

 

Will you get a pat on the back if you do a good job?

Be honest with yourself here. Try to envisage the scenario where you are toasted by top management for a great job completed and you have a warm feeling inside. Now step back from this to visualise the things management saw that made them feel like this about your work.

Are you still with me and are you still feeling confident about the outcome?

If you don’t know what success looks like there’s not much hope for stakeholders is there?

If nobody knows what success will look like, you are in a lose/lose situation, should you not be considering a new employer or maybe a new career?
What about all the loyal people who put up with you through all of this and received not a word of recognition, how will you motivate them next time?  

 

 

 

Reblog this post [with Zemanta]

When is a business case not a business case?

Read part one   part two Read part three  Read part four

  1. When it establishes that there is no case for the proposed initiative.
  2. When it fails to identify and present the benefits of the propsal sufficiently well to win support.
    Both of these situations have the same result only the second one is a lost opportunity for the business.
    A process for deveoping the business case for IT change

You can talk to five different people who have that word in their CV and each one will probably have a different take on what a business case is for, who should prepare it and what it should contain.
In fact, you could say that  the whole science around business cases, especially those involving IT investment has moved on substantially in the past two or three years.

Many of the concept of benefits were rarely discussed ten years ago, let alone benefits realisation.  Today all that has changed. Some examples of the importance this subject has achieved is the Cranfield university  Benefits Dependency Network Tool  and more recently the Microsoft REJ framework.
Here is a simple explanation that takes into account more recent developments in thinking and puts a simple framework around what a business case is and is not.
1. A business case must live up to billing and make a case for the proposed project. That means demonstrating how the project will deliver benefits for the business
2. A business case should take three forms,
a. Initially it should be an outline business case. This is a non detailed and very tacit explanation of why some very knowledgeable stakeholders feel that this is a very good idea.
b. A full blown business case with detailed cost benefit analysis and detailed financial calculations such as ROI, EVA, IRR,NPV etc
c. A one page summary of the final business case for people with little time for detail.
3. A business case must take a analytic view and not be an excuse to purchase my new toy, hence it should examine tactical solutions and doing nothing.
4. A business case should take into account political ,economic, sociologic and technologic trends likely to impact on the projects ability to deliver
5. It should take account of the organisations ability to deliver the project and realise the benefits.
6. The business case should always be a living document that is carefully managed by someone who carries a key responsibility for the project.

The diagram above shows a simple process for producing and managing a business case.
The top section represents the activities that generally occur prior to going into the implementation phase of the project .
The bottom section represents the activities that continue during and after implementation.
The first priority is to expand a little on the initial concept and capture high level requirements.   In dong this it will be key to get an understanding of the benefits hoped for by stakeholders and to abstract form them the knowledge and experience that has lead them to this conclusion and the assumptions that are underpinning it.
Next a high level examination of the potential solutions, include the ones that are likely to be already suggested, a do nothing scenario and a tactical solution.
From here an outline business case can quickly be created that encapsulates all the motivations, expectations and tacit understanding of the problem and potential solutions and provides a building block for stakeholder mapping.
In the next instalment we will look at some of my favourite tools for helping to create a business case that serves it’s purpose.

Read part one   part two Read part three  Read part four

 

Reblog this post [with Zemanta]