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.