New Diary/Activity Template

A few months ago I came across an adapted version of the Chronotebook, at The Geekette Speaketh. The Muji Chronotebook won an international design award in 2007, and is a very intriguing concept for a day planner. The Geekette adaptation is still around capturing the whole day, and I was thinking about how this might be adapted into a work day solution.

I used to try to do the GTD thing, but I didn't find that it fitted in my brain. So I thought I could include a bit of a to do list with it as well. What I came up with is below, with an example of how I use it beside.

 

• The concept is that the very inner circle would be what you need to focus on for the day - if there is a particular focus. 
• The next circle is your diary, where you put in your meetings and any scheduled time that you have allocated for particular tasks. I'm not all that good at ensuring that I have scheduled my work, but I'm trying to work on that.
• The outer circle is what you actually did during the day. I'm not entirely dogmatic about this, since I have the sort of job where I am constantly interrupted with short phone calls, questions and quick to answer emails it would be difficult to really capture everything. So there are sometimes gaps in things, or I just include it in the big chunk of work I'm doing.
• The last part of the circle is for reminders for the day - either for the start or end of the day.
• Below the diary/activity circle is a brief To Do List for the day. I've bought in a little of the GTD-type thoughts of classifying the activities a little bit, but I really don't find it onerous to bring tasks over to the next day if I have to.

I find that it is working quite well for me. I did a trial run with single pages and it worked quite well so I have made a bound journal with the pages now.

If you have any ideas about how to improve this I'm happy to hear it. If you're interested in using it yourself then feel free to download the PDF A4 document (which has two images, since they are A5). 

Exciting new personal project

Next Tuesday I will be starting a year long project based around a number of TED presentations, some of which were included in my previous post.

I have started a new blog to capture the A Year of TED project, which explains the entire project and will be a place for me to explore what I am learning from the inspirational TED speakers.

It means that I will probably slow down even further on this blog, but then again some of the talks are work related, so there may be some outcomes that end up in this blog - we'll see how it goes.

Things to inspire (from TED)

I'm a stumbler, that means I have a StumbleUpon account and waste hours of my life looking at websites I would never otherwise have found.  Fortunately I don't have children, so I have time to partake in this activity :-)

There have been some amazing sites and pieces of information that I have come across while stumbling that have opened up my world to things I might never have known about.  One of the most inspiring serendipitous stumbles I had occurred a couple of years ago, when I discovered Randy Pausch's final lecture and with it the wonders of TED.

Before I start on TED, I would recommend that everyone watches Randy's final lecture.  If you can get through the tears at the beginning and the end (I watched it on a train, not a good idea) this is an inspiring presentation that made me want to be a better person (don't think I've managed too much of that at this stage).

But moving on from Randy, since subscribing to TED through my iTunes I have encountered some equalling inspiring and really interesting presentations on knowledge, design, technology and the human body.  So my all time favourite TED presentations, the ones that I have carried with me and thought about incorporating into my life are:

Barry Schwartz on our loss of wisdom - moral will and moral skill, something really important to be aware of.
Rory Sutherland: Sweat the small stuff - the art of design and how we make things too complicated.
Alain de Botton: A kinder, gentler philosophy of success -  which is a fascinating insight into what might actually be making us all anxious and miserable.
Elizabeth Gilbert on nurturing creativity - which just makes sense and I think anyone with creative talent needs to watch.
Don Norman on 3 ways good design makes you happy - love the enthusiasm
David Logan on tribal leadership - I found this one to be so interesting that I have since purchased his book, with Steve Zaffron called The three laws of performance. This is an amazing book that makes a lot of sense but helps you look at leadership and performance in a very different way - I highly recommend it.
David Cameron: The next age of government - for a government worker, and an information manager, this is very interesting
Tom Wujec: Build a tower, build a team - I would love to try this with our current organisation
Any presentation by Ze Frank - but I love his website as well http://www.zefrank.com/
Aimee Mullins Opportunity of adversity - another inspirational one
Jill Bolte Taylor's stroke of insight - this one is great for the human body stuff
Being a person that works with data these are spectacular:
David McCandless: The beauty of data visualization
Jonathan Harris collects stories
Jonathan Harris: the Web's secret stories

The thing is that there are easily another 40 presentations that I could link to here. As a matter of fact I started writing this post months ago and the reason I haven't posted it was I didn't feel I had included all of the presentations I thought were brilliant, let alone the ones that are just intriguing or interesting. Then as I worked on it more and more presentations were added.

Today I just decided to post it and let you guys trawl through them all for yourselves. There is an amazing presentation from a journalist who became homeless for a year, brilliant presentations on all aspects of design, amazingly inspiring presentations from people who have overcome so much.

But enough of my raving, if you have not yet entered the world of TED.com go and have a look, there is bound to be something or someone that will inspire, challenge and teach you something.

eDiscovery Conference and Presentation

Last week was the eDiscovery conference in Melbourne that I was asked to present at.  I did decide to use Prezi for the presentation, which I think was really the best choice as the presentation really lent itself to this format.  The presentation is available at prezi.com.

The talk itself went down fairly well, as well as I guess I could expect in a room that was mainly legal people and vendors.  This was the problem, in my opinion, the conference was a very intriguing mix and I really don't know that the Information Managers who were asked to speak were really given a good enough brief about the focus of the other people in the room to make our presentations meaningful to everyone.

For me, I really enjoyed the IM briefs and quite a few of the eDiscovery process ones as well, there were issues I had never really considered that helped solidify for me that the focus of the work I am doing will be very helpful for the business in the long run.

Maybe I am misjudging the level of interest from the legal people, maybe they really did get something out of our presentations as well - guess I have to wait for the feedback to really find out - it just felt like there was a bit of a disconnect between what each side of the room might have been trying to get out of it.

I know that the focus of the conference was to bring IM, IT and Legal together, and Warren tried very hard to do this in his chairing role - it just seemed to lack some unity for me. And that is not saying that I didn't think it was worthwhile or interesting, I really got a lot out of it, just not quite cohesive.

Sometimes it is just your job to listen

I feel like I have become a bit of a therapist in the last couple of weeks, as I have started conducting the needs gathering workshops within the organisation.

The way that I have approached this is that I have provided them with a template to capture the information they need to do their jobs; the information they create as part of their jobs; the IT/manual systems they get information from and put information into; the people they rely on for information and the people they communicate information to; and finally the limitations that they experience in all of these areas.

Many of them haven’t done the pre-work, but it is a good template to commence the conversations around.

On the whole the majority of the comments are not unexpected, the revolve around communications, standardising procedures, better access to the information they require, sorting out the shared drive, having compliant and accessible systems and so on.

So why do I say I feel like a therapist? Well there are a lot of these areas that have obviously not had someone sit down with them and give them the ability to explain where corporate systems are not supporting them properly, or where they struggle to find the information they need, or anything along these lines really.

So I’m getting everything relating to processes, organisational structures that don’t work, corporate policies relating to vehicles and any number of other frustrations coming through in the discussions.

But don’t get me wrong, I’m enjoying the process and some of the conversations have allowed me to fill some gaps in my corporate knowledge in the process. And, above all else, I think that it is important that staff are given the chance to get these frustrations off their chest. Does it mean I will be able to do anything to influence changes to many of these issues? Of course not, but as the title says sometimes it is just your job to listen.

And for the things that I can influence? They will go into the Needs Matrix for inclusion in the Information Management Strategic Plan.

The Project Team - Project Series

I know that I have moved away from this series for a little while, but there are certainly still a few areas that I want to examine, comment on, whatever it is I'm doing here.

The next one is the structure of the Project Team, and more particularly, the business representative(s) on the project team.

Unfortunately projects involving IT can take a while to get in place, and organisations are not usually staffed to be able to lose valuable operational staff to a project for a long period of time. This brings another tension into projects that have IT components, since the business is reticent to lose skilled staff for long periods, so they will pressure the project team to deliver earlier, or make their staff member(s) available 'as required', or in the absolute worst case give the project team a staff member they are willing to part with for a long period.

Rule #1 for the business unit should be when choosing the business expert to give to the project team it should be a person that you really can't do without. Or put another way, if you are happy to let a person go to the project they are the wrong person for the project.

This is not rocket science. The role of the business expert in the project team is to inform the project and development staff about the business processes, and make decision about the product that the business will have to live with. So think about it, surely you don't want to give them a staff member who is less than effective in their role? You want to give them the person who understands everything, you want to give them the person that everyone else relies upon for support and assistance, you want to give them the person who you trust to train new staff in the business processes. It stands to reason that this would be the case.

However, as mentioned earlier you can't afford to lose this person for a long period of time, so what does the business do? This is where a lot of projects fall down. We had a project in Defence that was developing a system to support a particular business process. A position was chosen as the liaison point, which was not the best position but the business couldn't spare the people who actually did the job. The person in that position had their own thoughts about how things 'should' work in the space, and had the system designed to support their view of the world. Needless to say that there was a significant redesign task when other people finally saw the system.

The thing that I have learned is that you cannot rely on one person to inform the project of how the business works, and most projects seem to understand this. There should be a business person on the project team, someone to keep the IT people on the straight and narrow when they get too focused on the technical aspects and lose sight of what the system is being designed for (it happens). The business person is also an important role to assist with the communications and training development. But it is even more important to ensure that the project team has a stakeholder group with your best staff, and that they are engaged appropriately in the process of developing the system.

There should be a Goldilocks approach to this consultation - not too little, not too much, just enough.  The stakeholder group should not be asked to validate everything the project business member says, but they should be asked to validate processes early on, they should be shown the developing system at key times in the process and of course they need to be part of the test and trial process before full UAT is commenced.

A note for Project Managers and BAs - when you are developing the business case and doing process mapping ask the question 'who do you go to for help?' and ensure that the 1 or 2 people that the majority of staff mention are requested to be part of the project. Put the business on the spot to say that they won't give these people up and identify the risks involved. In my experience the business seldom thinks of the actual impact of giving you less than optimal staff.

Information environment presentation - progress

The presentation for the eDiscovery conference is coming along fairly well. I have decided to do it in Prezi, but I will have a backup in faithful old powerpoint just in case technology fails me.

I've come up with a closing quote for the presentation that I'm pretty happy with:

When we know what we know and where and how we keep it then we know how to discover it

It's only recently that I added in the "and how" part, but I think that is one of the most important parts in an eDiscovery sense.  I'm pretty nervous about this presentation actually, since it is the first time I'll be presenting at a conference that is not focused towards records and information managers, but we'll see how it goes. Surely lawyers aren't that scary :-)

And now for something completely different...

I usually don't do posts that are simply links to other people's blogs, but I really need to make an exception for this one for two reasons:

1. This is one of the most romantic things I've ever seen (read), and not just what Sid did but also the song - which is free for download from the Heartless website (the movie is really lovely too.)
2. It not only has muppets in it but I have learnt from this post that it is possible to design and purchase your very own muppet Whatnot!!! Which I must say is a super-cool concept, even if the online store doesn't ship to Australia.

The post is about a wedding proposal with a difference, and it is lovely to think that after ten years together he would still go to so much trouble to propose. The cynical part of me thinks he wanted an excuse to make a muppet movie, but the effort to get it into a cinema belies that :-)

Maybe it is just the Krismas spirit, maybe it is the hopeless romantic in me, but I just had to share this one - enjoy.

Conference presentation on the information environment

I've been asked to present at an Ark Group conference on eDiscovery next April in Melbourne.  After considering it for a day or two I have suggested that I could talk about the information environment, documents and frameworks involved and how setting this up can assist in the eDiscovery processes.

I've started working on the presentation, and will hopefully get to use my current working environment as a case study, since we are progressing the artefacts for the information environment.  One of the things that it has reinforced for me is the importance of Security Access Models for all IT systems, which I presented at an information management policy conference three years ago. I have developed this further over the last few years and will be including this in the new presentation as well.

I've also come up with a much more refined image of the artefacts of an information environment. It's like a building blocks structure from bottom to top and I think it is a little more succinct and accessible to management. I'd be interested in any feedback on it.

Once I've done the new presentation I will post it up into Slideshare as well, unless of course I do decide to use Prezi for this one (I'm seriously toying with the idea but don't know if it will be too distracting).

Personal reflection

Do you ever have those days when you go into work and think "today will be the day they work out I'm a fraud"? I don't know why we do this, and I say we because I actually learned in a coaching training (don't ask) that this is an acknowledged condition (mainly in women not surprisingly).

I've been feeling a little overwhelmed at work this week, so much to do so little time, and so this feeling has been allowed to creep into my daily thoughts. This completely sucks, because usually it is when I have a really heavy workload that I'm more prone to these thoughts, but this is when I just need to kick in and get things done without any self-doubt.

Maybe this is just a little glimpse into my psyche that I shouldn't really share, but at the end of the day I am not a fraud, I know my job and I do it well - either that or I'm a much better bluffer than I ever thought possible. Next post will be more informative and not just about my mental processes - promise.

When not getting funding is better than getting funding - Project Series

So you've jumped the hurdle of the business case and your project has been given approval to proceed. You're patting yourself on the back and then you find out that the funding is conditional.  In my opinion, because I have had a rather important project that suffered this fate, you are better off having the project delayed or rejected than having someone say "we've approved the project and given you the $500K, but it's only for this financial year, so you've get to get it in by 30 June."

These artificial deadlines can set a project up for failure and don't allow projects to be run properly. But can you really say "thanks but no thanks" when you get this conditional approval? This depends on the business you work in but, having gone through the grief of this once before, I will push back if I am given an artificial deadline like this again.

If you have been very clear in the business case about how long the project will take, then you have a very clear position to push back on - basic project management theory will tell you that if you want to reduce the time taken for the project then you need to increase the money and/or decrease the scope.

But if you are undertaking a project that has a large cultural change component then, in my opinion, it is not possible to reduce the timeframe without significantly impacting the success of the project. People need time to be consulted, time to review, time to absorb and adjust to the changes - conditional funding or not.

As a side note to this, if you have minor upgrades/enhancements sitting on the shelf and funds have been made available (you know that end of financial year spend) then you can probably go for it and get the benefits of conditional funding - but it is not the way to fund an important business project (IT based or not).

Minor successes - major plans

I've blogged a couple of times about the information environment and how I may have a chance of finally being in an organisation where I can implement it.  Well good news, the organisation has agreed to proceed with implementing the Information Management Strategic Framework that I have developed for them. It is the beginning of a long process, but they seem willing to take the long journey of getting this sorted and doing it right.

There are two next steps to build the information environment, they are conducting an information audit to develop the Information Inventory and conducting a needs assessment with the business to develop the Needs Matrix.

It may take up to 6 months to get this process completely finished and get all of the documentation finished, but from there we can develop the Information Management Strategy, which will feed into the ICT and RIM plans.

While we go through this process we are still going to proceed with the Records and Information Management Improvement Program that I have developed. This is designed to sort out naming conventions, the shared drive and finally an EDRMS implementation - which can happen alongside the other development work.

So it is full steam ahead it would seem - I'll keep you posted on the progress as it goes along.

Problems with the Business Case - Project Series

This part of the project is very dependent on the internal processes within the business, so the things I say here may not be valid for some businesses.

Defining the Business Need

Business requirements have been covered in an earlier post, this is more about the need for the project, what will it achieve in the business.  Another earlier post addressed the requirement to not allow bosses wanting something bright and shiny or IT staff wanting to play with a new technology to drive the business need.

A good Business Case template will of course require you to define the Need, the Drivers for Change and how this project will add value to the business - and that is extremely positive, because if you can't define these qualitative features then the project should not be progressed beyond someone's bright idea.
But often times people look to a technological solution for business process problems.  This results in leaps of analysis, where the new system is the silver bullet that will resolve all of the businesses woes, streamline the processes to produce cost savings, bring about world peace and so on.

There is a saying "you can put lipstick on a pig, but it's still a pig" - you can put in a multi-million dollar IT system but if your business processes are broken they will not necessarily be resolved by an IT system.  If your project incorporates a significant change process and addresses the procedural shortfalls then it is likely to produce the improvements, but if you had undertaken the change activities without introducing the technology what would the outcome have been???

Defining Return on Investment

My biggest bug bear with Business Case templates is the financials, and not just because I get no joy from working with numbers.  The main problem is that the projects that I am usually involved in have a negative rate of return due to the inability to adequately capture and define the efficiency improvements per individual. How much money will the business save putting in enterprise search? Well I'm sure I can get some Gartner figures on time per day spent on search and average that out for the business, but what if you company requires you to actually deliver that as a direct cost saving?  If I am saving everyone in the business two hours a week of lost time I am making them more efficient, making them happier in their jobs and able to respond in a more timely manner, but I'm not actually saving tangible and definable dollars.

There needs to be a better way of defining qualitative ROI to the business that does not have to be delivered in actual cost reduction.  I've been thinking of something like a Goodwill Indicator. This would work along the lines of how beneficial the system will be to the staff - those qualitative results that cannot be easily measured and will not see clearly defined savings but will make it easier for people to do their job.  I think it has some merit as a method, but I need to flesh it out a little bit.

What else?

Whilst I understand the need to have a detailed business case it is very disheartening when everyone just reads the Executive Summary and the little bit that they are interested in.  Yes a detailed business case proves that analysis and thought have been put into the project and the need for it in the business, but there needs to be a better way of proving that this work has been done without the need for a 40-50 page document that virtually no one will read.

I think we need to come up with some smarter documents around all of this that make it simpler to create a well thought out business case.  Importantly, even if your business has good templates I think that it is extremely important to develop a clear instruction, a checklist even, about all of the hoops that people must ensure they go through to develop the business case.  Developing a good business case is hard enough without knowing exactly how to do it, who to engage and the standard process.

Functional Classification Presentation

I've been working on a presentation for a few weeks, starting to prepare for the inevitable discussions that will have to occur here on functional classification of documents.  I had a thought a few weeks ago, and a whole stream of explanation started making itself clear in my mind, so I thought I would spend some time at home coming up with a base presentation.

I complete it last night and its now loaded into Slideshare if you want to see it. Because they're having a contest I already ticked that box, not that I think this is one of my best presentations or because I think it's a sexy enough topic to win, but because the option was there in the list :-)

Not surprisingly, my closing advice is the same for everything I talk about in records and information management - train your staff on how to do their jobs and life will be so much easier.

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.

A metaphor for "IT Projects"

This goes along with the Project Series posts, but is not the next post I planned to make.  But, I was very happy with this metaphor, which I am going to use to try to explain some things to management in my organisation.

Basically, my organisation deals with assets, so I started thinking about building projects and how I might be able to explain the importance of the end part of "IT projects".  The problem is that there is a perception (which is not unique to my organisation) in management that when the system is turned on the project is complete.  Nothing could be further from the truth.

So what is my metaphor?

Building a House

When you commence a project to build a house you know that the project ends when the house is complete and can be occupied.  When a project to implement a system is "complete" is a little more difficult but...

If you think of the "go live" date as the house being in lock-up stage then I'm hoping this will help the managers.  Basically, when a house gets to lock up from the outside it looks like a house, but it is really just a shell that still needs a kitchen, bathroom(s), painting, floor coverings, services connected and everything else to have it fitted out.  You don't close the project and redirect you building project manager to another build at this stage.  They are required to stay on board until a Certificate of Occupation (or some such documentation) is received for the building - that is when the project is complete.

IT Projects, or specifically projects that have an IT component, are exactly the same.  Go live is like getting a house to lock up stage.  The project still has a long way to go until completion.  The system needs to be bedded down, bugs need to be fixed, tweaks done, documentation completed, integration completed, training undertaken, support procedures put in place and a number of other minor tasks.  Whilst many of these should have been planned for and commenced during the development phase of the project, it is not possible to have them all complete and implemented by Go live.  Therefore, the Project Manager and project team still need to exist, maybe in a different configuration, until there is a sign off that the business has accepted the system, or is deemed occupied.

So that's my metaphor, I may even do a brief about it and if I do I'll put it into Slideshare and link back.

Epiphanies

You know how sometimes you are sitting there talking about things and a thought comes into your head that you think is pretty cool, well I just had one of those. Very soon I will be briefing our Executive about improving our records and information management. I was thinking about some of the databases that we have and playing with words in my head about trying to get them to understand the importance of this data and how we can use it.


We're so used to thinking of documents as "unstructured data" but the thought I had was this:

Data is an unstructured document that is yet to be developed into a story.

I don't know whether this is any sort of revolutionary thought as yet, but I am hoping that I can develop it to make it something that will help the Executive understand the value of our analysts and reporting regimes.

I'll have to think about it a bit more...