Business Requirements - back to projects

When I worked in Defence we had an area of the organisation that would come to us every 6-12 months and say that they needed a system to support their work.  Usually this request came along with a solution, you guessed it they'd seen something bright and shiny, liked the way it solved someone else's problems and thought "that will work for us".

Our answer, for the five years I worked in that role, was the same every single time "write up your requirements and we will investigate the products that are available and work with you to get a system that meets your needs".  Since we dealt with this every 6-12 months, how often do you think they actually put in the work to write up their requirements? Once, when one of our team did it for them. So how many systems do you think we delivered for them? Zero (two versions of a system were delivered but it never went into service, don't ask!)

So why couldn't they just sit down and tell us what they wanted? We would have been happy to oblige, even with some of the tools they were suggesting, but we needed a requirements document to do anything about it (that was the process, and a good thing too I believe).

Getting Business Requirements out of the business
My opinion is that there are two things wrong with Business Requirements, or the way that we go about doing them for IT systems.  The first is that most people either don't really know what they need, or they don't really have a "need" it is more of a want (which can still be valid).  The second reason, and I think this is the main obstacle, is the Business Requirement document format.  I've had people say to me, "I can't do all that 'Shall' stuff, it makes no sense to me", and even people who have a business analyst at their disposal have been reticent because "last time I didn't understand the document and the system turned out to be all wrong".

The average person in an organisation doesn't care about all of the gumpf that has to go into a "proper" functional requirements or business requirements document.  They don't care about use cases and shall statements, they want something that in plain english captures what they need and want from the system.

Does the formal business requirement document need to exist? Yes, I believe it is probably the best mechanism for the business analyst to communicate with the technical staff who will be developing the system.

Should the people in the business who are requesting the document ever see it? No! The role of the business analyst is supposedly to be the conduit between the operational business elements and the technical staff, so make two documents.

Having been involved in a number of "requirements capturing" exercises over the last ten years, I believe that they are one of the most boring, drawn out and complicated experiences.  Sitting in rooms going through line by line of requirements gathered from workshops and prioritising them, categorising them, working out which ones contradict each other, which ones are a pipe dream and so on, should be against the Geneva convention.  It is cruel and unusual punishment, and I know why some people in business will just do without a system they desperately need, rather than being involved in these processes.

There needs to be a better way. I don't have an answer for this yet, I am trying to come up with something in my own mind, but I do have some suggestions:

• plain english must be used with the business, convert it later
• simple diagrams should be used to convey interaction with the system and information flows, but they must be simple and don't need to capture everything (we had one BA in defence who created flowcharts from hell, A3 pages that were interlinked, containing data feeds and processes. Every permeation was captured, it took about eight months to complete and by the time they were published they were incorrect.)
• it must be a rapid process that does not involve the staff wanting to kill themselves to get out of the meetings, this is why incorrect requirements go through to developers, the business have been numbed into submission
• ask them whether they have seen any other system that does what they are talking about, even if it is completely unrelated to their system. For example, if they ask for a way to pick dates ask them if they want it like an airline website. Most business people talk in this way anyway, I've lost count of the number of times I've been asked for a function to search "you know like Google".
• ultimately I think that there needs to be a better language for doing this, and better systems. Rapid prototyping, even if it just a visual representation that doesn't have all of the grunt behind it, is an absolute must.
• ask the right people about what they need (I'll talk about this in more detail in a later post about business representation on the project). If the business can spare someone to spend days or weeks to help you develop the requirements, you are talking to the wrong person!

A final note for BAs (for now)
Business analysts, especially consultants brought in to do this role, need to remember that everyone is not equal in the requirements gathering process and you have to keep it on track for what the business area who has initiated the system wants.  Scope creep kills projects, so you should focus on what the person paying you is asking for. By all means raise functionality that came up in workshops, but if you are told no, listen!

I had an extremely frustrating experience in my last role. The consultant had his own agenda about what we should be asking for, even though I had made is very clear to everyone that we had to draw the line with the requirements and a few features (namely the things he was pushing) were out of bounds for discussion at this stage.  He raised it in the meetings saying things like "and don't you think it would be good if it was accessible to people outside the organisation?", until I snapped in a meeting and told him off. We went toe-to-toe about these requirements, I told him they were not to be included in the documents or else the project would not get up. He was taken off our project, and had we not be tied to the organisation and on such a tight timeline, we would probably have gone in another direction entirely.

More on the Information Environment methodology

Ever since I've been doing corporate information management roles I've had this theory about how businesses could do all of this better.  It's been evolving over the years, and I think that I've finally got it sorted inside my own head now.  The exciting thing for me, as mentioned previously, is that my job is really a blank slate to trial this whole thing. I'm not sure yet how supportive the Executive will be with it all, but I'm hoping to convince them that we need to do this work so we can truly know where we are and plan to get to where we want to be.

I've fleshed the previous image a little more, and actually have some of the templates developed.

Proposed structure of the Information Environment methodology

As an aside, I hate methodologies, mainly because I've had some less than optimal experiences with people who seem incapable of operating without one, and blame any lack of progress in a project on the "methodology" and not their own inability to understand some extremely simple concepts. Maybe I should come up with a better term... I'll have a think about it.


So what is this and what do I hope to achieve with it?

In my experience, organisations make some less than optimal decisions about information systems, and therefore how they should be spending their time and money in the information space.  I've previously written about the problems with management and IT making decisions on these things, and my aim is that having this structure in place will reduce some of these problems (I know, I'm an optimist).

The diagram shows the elements that need to be in place to support good decision making, and an operating environment that is easily navigated by everyone involved.  How many times have you started a new job and not known where to look for the information you need to do said job? You ask the people around you and they say things like "you need to get access to the X system, but I don't know who does that?", or "I don't know the proper way, we just ask Mike to email us the report" or other such nonsense.

Wouldn't it be nice to walk into an organisation and have a roadmap of the information environment, what information is contained in which system, how to get access to that system and how that information might link up with other datasets? As an information manager that is my utopia! If I could do that for an organisation then I would feel like I had really done my job.

I think that the diagram is fairly self-explanatory at this stage, but in future posts I aim to flesh out each of the elements of the environment, to go into more detail on the role they will play in this utopia.  As I mentioned, this has been going through my head for over five years now, and I've really only just worked out how some of this hangs together and how the elements will support the business decisions.

I would really love any insights that other people might have on this, maybe it's time to put the blog into my LinkedIn and see if I can generate some traffic.

An interlude on information environments

This does have a lot to do with Information related projects, but it is not the next part that I intended on talking about.  In my current role I actually have a change to affect real change, or at the very least set up an information environment and have everything defined the right way. 

I'm going through the process of trying to work out how to achieve this at the moment and at a very basic level below is a diagram that I think covers the pieces of the puzzle:

Elements of the Information Environment

I know that this is very broad and contains no real descriptions, it is something that I hope to flesh out in more detail as I start trying to sort it out in this organisation.  I will update it as I move along, and who knows, it might end up being another ebook topic (complete with templates and the like).

Of course I do have to be careful with it, this document was created on my time, and my system.  So I am not sharing any of the organisation's IP for this.  But it will be an interesting challenge on where to draw the line, after all this stuff has been swimming through my brain for years now.  So is it anyone's IP but my own, regardless of who I work for when I finally write it all up?? 

But that's a whole other blog post...

Appropriate triggers for projects

These posts are not rocket science, I am not saying anything here that hundreds (or thousands) of other people working in organisations all of the world say.  I guess I'm just attempting to get it all in one place, provide other people with the sanity check that they are right in thinking things aren't right, and offering some advice or suggesting better ways.

So with the first real blog of context around IT related projects I've decided to start at the beginning - the trigger for a new or upgraded IT system to support the business.

Simplistically, there are only three appropriate triggers for commencing a project to implement or upgrade an IT system.  These are:

1. there are well defined requirements that the business has developed to justify an improvement to work processes through automating them with a system
2. there are compliance issues that are driving the requirement for a system that can better support the business processes involved
3. the current software/hardware can no longer be supported within the IT environment, or no longer supports the businesses needs

Now these are pretty huge categories, and can break down into very grey areas, but that is basically it in a nutshell.

Most importantly, there are two triggers for commencing an IT related project that are unacceptable and completely invalid - and these are the definite areas to avoid.

The Management Decision

Deep breath and let's go... It is never acceptable for people in management (even the CIO/CTO) to select a product for the business.  Most of these decisions are based on sales pitches, which show them lots of pretty graphics, customised workflows and reporting screens that make them ooh and aah.  They think that they are doing the right thing by asking whether it will allow their staff to X and Y, and of course the vendor says yes.  If the CIO/CTO is involved they might even ask if it is X database or runs on Y servers so they can tick the box that it is right for their space.  But this should be avoided at all costs!!!

I have been involved in implementing and using systems that have been "management" decisions.  They seemingly ticked the really important boxes in the requirements, if there were any, but were so far removed from the actual business processes, or were completely different technologies than anything else in the environment.  There was one product in Defence that everyone knew was a bad decision, the joke was that they put on the best entertainment when the boss went over to the States to review the products on offer.

So why shouldn't management choose products?  Please remember that I am talking generally here, this is not the case for everyone but in large organisations it is often the case.

1. They don't perform the tasks - if the Undercover Boss tv series has proven anything it is how people sitting at the top do not understand how the work is really done.  If they don't perform the tasks then regardless of whether "this product has been successfully deployed in X, Y and Z" they cannot know whether it will support the way their business works.  Now, I don't subscribe to maintaining status quo in all business processes through automation - as a matter of fact I think that these sorts of projects are a great way to identify the outdated processes and overhaul the thinking behind them.  But, you can't shoehorn an entire business into a piece of software just because it works for a related process in another business, even one in the same industry as yours.  
2. They don't know what else it may need to integrate with - this is a big one, and unfortunately for many organisations no one knows exactly how all of their systems hang together and how they are used by all areas in the business.  But management are even less likely to know.  Will the system need to get base data from another system? Does that other system have the capacity to talk to this one? Will some other data exchange need to be developed to make that happen? Is there any other system that will be reliant on the new one for data? How is reporting on this information done and will the new system support it?  An IT system for your warehouse is seldom a completely contained system that only needs to work with the processes inside your warehouse - it will usually have to link to point of sale systems or financial systems or even possibly staff rostering systems.
3. They don't know what technology their business supports - if your business has all Oracle databases and you decide to acquire a product that runs on Sybase what does that mean?  Generally it means getting a Sybase administrator (or two or three depending on availability required) and purchasing new licenses - was that factored into the vendors sales pitch?? Doubt it!  What about if all of your systems are on Microsoft servers and this requires Unix servers? Not only are you up for more administrators but also extra hardware and licensing again.  As much as the current technology should not drive all future decisions, the impacts of the technology on the business (personnel and costs) must be considered and incorporated into the consideration of any product.  A "bargain" $150,000 system could cost the business two to three times more in annual running costs.
4. Vendors are liberal with the whole truth - I am not going to say that they lie, but they do certainly paint an extremely positive and optimistic picture of how their product is the best one for your business and how it will help you.  It is not their job to point out to you where all of the hidden costs are, and how the software costs they are quoting you are likely to be the smallest cost in the whole project.  It is their job to get you to buy the software (or hardware) and hopefully hire them to integrate it into your environment, because that is generally where the big dollars are made.  One thing that anyone dealing with an IT systems vendor must remember is that a system can probably be configured/customised to do anything or integrate with anything - but there will always be a cost in time and money to make it happen.  So if you say "can it produce my monthly report?" the vendor will say "Of course it can" - the question you should have asked was "How much time and money will it take to configure the system to produce our monthly report in this format?", as you hand over an example.

The IT Department's Decision

So if management shouldn't pick the product because they don't know exactly how tasks are performed in the business then we have to examine the validity of the IT Department selecting any products.  They seldom know exactly how the business works, and unfortunately in my experience many people in these departments don't care - noting that people in finance or HR don't necessarily care how IT works either, so it is not a unique issue to them.  Whilst supportability of technology is valid it shouldn't drive all decision-making, but many IT departments believe that they should have the final say on all product selection.  And unfortunately, the current paradigm really lends itself to them having this control, as the minute a project will include an IT component it is usually handed over to the IT department.  There will be a later post about how ridiculous this is, but that's for later.

As an information manager I have strong objections to IT choosing and implementing systems.  My biggest problem is around the "throw it out there and just let them do what they want with it" technologies.  By this I mean things like Microsoft Access, Sharepoint, wiki software (like Confluence and the open source systems) and even standard intranet content management systems.  Whilst most of these can be implemented with strict creation controls which allow the business to manage their information repositories, they can also just be put out there for any team/individual to create a space and lock it down, making it almost impossible to manage in any way.

But onto the reasons why they shouldn't choose products:

1. They don't perform the tasks - for all the reasons mentioned above, but this is an even bigger issue than management in many ways.  There are a lot of IT departments that seemingly have no idea what the business does and what the most important functions are (many others do but we're talking general here).  And now I am really going to get some people's hackles up here, but in my experience many (not all) of the "Business Analysts" employed to ensure that the IT department does understand what the business does are not skilled.  Ok I will clarify here - I have worked with some exceptional business analysts who can walk into a business unit and really get down to the nitty gritty of it in a short time, but I have worked with many more who cannot grasp the workflows and terminology used, even after two years of close contact with the business (don't ask).  Maybe my experiences are the exception, but I've spoken to other people who also have the same opinions, so I don't think this point is invalid.
2. They don't know what it may need to integrate or comply with - the reasoning for this is nearly exactly the same as point 2 above.  I will add that for IT departments this can be a bigger issue because of the compliance requirements.  By this I mean if there are recordkeeping requirements, if there is a metadata standard that should be used, or if there are security compliance rules around logging and monitoring.  Management will usually have a better idea of these, especially the latter ones.  The people actually performing the tasks, and the governance and compliance specialists in the business that should be involved in the projects will always know.
3. They may have a personal interest in doing so - again let me start by saying I have a lot of friends in this industry, but... there is a chance that decisions are being made to support resume building or because there is a new toy to play with that they really want to get their hands on.  The business can also be to blame for this, I'm sure there were many wikis and blogs implemented as "must haves" in businesses throughout the world in the last few years that have now slid away into oblivion.  But the IT department will generally contain more Innovators (in the Technology Adoption Life Cycle model), so they are keen to get the toys and have a play, and if they can do that during work hours then all the better.

The next post will deal with Business Requirements, and some of these things will be addressed in more detail again.  I won't apologise any further for the content of these posts, I have put disclaimers in here all along the line and I will try to be a bit braver about it from now on.  This is my opinion, based on years of experience and talking with other people about their projects.  No group in this is entirely good or bad, I will try to be even handed here, and I will even bring up what information and records managers do wrong as well.  Before anyone takes offense to any of this and comments (which I would encourage - commenting not taking offence) take a breath and think about why you are offended, and whether anything I've said here is entirely wrong.