The importance of As-is analysis

Why do an “As-is” analysis?  Before we answer that question, let’s take a broader look at Business Process analysis in general.  When we start process analysis, we start by asking the Stakeholders: what do you want to get out of this project?  This helps to form a vision statement, which at its heart aligns itself with: save time, use fewer resources, or save money.

We also wish to gauge the client's expectations.  Finally we wish to implement a strategy designed to meet those expectations as best we can.  To ensure we meet those expectations we need to be able to prove it in some way.

It’s here where the “As-is” analysis starts to become important to the overall success of our project.   At the same time, it is here that we can start to get into a little trouble.   Depending on the point of view of the Project Manager or the Client, they can often see the “As-is” analysis as just overhead; that this step in the overall project success is superfluous and therefore not required. 

The problem

Depending on whom you ask, you'll get some very different opinions on what is important to the success of a Business Process project.  Each project has its challenges with: budgets that match my weekly coffee expenses; to timelines that made you realise how precious a minute can be.  In these types of project challenges we're always looking for ways to deliver quicker.  The faster we can work towards the end goal the closer we'll be to the budget or timeline.

The “As-is” process is oft times raised as an overhead.  The argument against completing an “As-is” analysis goes something along the lines of: 

• We're here to improve the process, not deliver the existing process; 
• The documentation produced in the “As-is” doesn’t serve any purpose and no-one will end up reading it;
• Why spend all this time worrying about how they currently do things when we can just dive in to how they should do things? or 
• That it simply inhibits the creative process.

If you have ever faced this situation or would struggle to justify the “As-is” process being included in the project delivery, hopefully we’ll be able to address some of these key concerns and ensure that we all can understand why “As-is” analysis is important to the success of the project.

Consequences of avoiding the “As-is”

What are some of the consequences of skipping this step in the delivery?

Diving straight into creating the “perfect world” scenario has its short-term rewards. The project has saved time in the delivery cycle. That's got to be worth something.

However, old habits die hard. Not mine, but the people within the business. When we introduce a new process without fully understanding the old process, we lose some of the justifications to why the old process existed. Whilst not all reasons for existing processes are well thought out, they do give us an insight as to the behaviour of the people and systems involved.

When confronted with a scenario that the new process perhaps doesn’t cater for, or handle well, the people involved will need to resort to their own devices. They'll look to how they used to handle this scenario previously and fall back on old habits to get things done. All of a sudden our shiny new process has a flaw. Trust in the new process gets a little shaky. The adoption of the new process soon becomes an issue.

As a consultant, I get sent to analyse processes in many different industries, from finance to mining, from local council to federal government. Getting to know the terminology within each industry and their thought process is important. Getting to know the constraints and boundaries of what each industry can and cannot do is also an important part of the "As-is" process. It helps me get to know them.

Moreover, it helps me understand why the process exists the way it does. If there is a clear reason for why a step in the process exists then I can make an informed decision of the validity of that step and whether this needs to be addressed in the new process. If no one knows why a process or a step in the process exists, then we need to tread lightly. We need to investigate this step further to make sure we are not missing something important.

Measuring success

If I have a car, and I came to you, the master mechanic and said, I want you to improve my car.  I want it to use less petrol per 100km. 

Would you just start by giving me a magazine and circle all the top ten cars for fuel efficiency and get me to buy a new one.

Or would you start by asking what type of car I had?  Why I chose that car?  How old that car is?  How fast I drive that car?  How far I drive it?  Is it an automatic or manual?  How often I accelerate?  If it's a manual, how many rpm do I let it get to before I change gears?

If we go the path of the magazine, and reengineer the process, we might not discover that they just bought a brand new car last month.  That the car they bought might already be the most petrol efficient car on the market.  So our great idea is now to sell the month old car at a loss and buy the same car again… but maybe with a different colour.

The improvement they required might be a habitual one.  They may just need to slow down, or accelerate less, or use petrol with higher octane.

All that may need changing is the driver’s bad habits.  It could be that in the end, that is all the process may need.  It might be that the process is sound but that the people within the process need to be (re-)trained to ensure more efficiency in the way they work.

We won't know until we see what the "As-is" process is first.  We can measure how much petrol is used per 100km.  We can then come up with a process improvement or change that proves that we are beating that number.  We now have set the expectation.  Our job now is to meet that expectation.

Get to know the beast

Before working out a plan for a "To-be" process, I need to know the "As-is".  Not because I like living in the past.  Not because I want to use this as the basis for my "To-be".  Not because someone said I have to, and therefore I should.

What I want to get out of the "As-is" process are the following:

• Where are the current bottlenecks?
• What are the current process dependencies - which processes are dependent on it; and which processes does it depend on?
• Who are my direct actors - people that directly affect this process; and who are my indirect actors - people that don't directly affect this process but have some stake or interest in it;
• Depending on what I've been asked to improve or automate, what are the metrics I can get from this process; how much money is spent on one process, and at each step; how long does the process take overall, and at each step; how many resources are involved in one process, and at each step;
• Which systems are involved with this process - are there any legacy systems; are there any external entities or people outside the organisation, such as other government agencies or something as simple as PayPal;
• And how do people within this process like to work.  What are their personal habits?  How comfortable are they within the process and how receptive are they to changes. 

Processes often get convoluted over time.  The reasons can be varied, from:

• Some legal change that got forced into an already flawed process;
• Changing of personnel or management; or 
• System dependencies that enforced process change.

Understanding how the process got flawed is an important step in understanding the business and the people within the business.  Once I know this information, I can start making informed decisions on what the “To-be” process will look like.

 Producing useful documentation

Part of the reason for the “As-is” step being seen as overhead is in the type of outputs that are created as a result, and how long it takes to produce those outputs.

How much time should this part of the analysis take to collect and document?  And what type of documents should be produced.

For me, analysis should take up to 15% of the overall project time.  So if you have 30 days to deliver, you should probably stop reading this blog and start working on your As-is process analysis.  If you have 12 months, then a month and a half should be reasonable (doesn't have to be spent in one go mind you!).

What type of documents should be delivered is an interesting question. 

Most people end up producing some type of Flow Chart with swim lanes in a Visio diagram, along with an accompanying document describing the diagram.

 

I like to go the extra mile, even if it takes a little longer to travel.  What I like to do is to Storyboard the process.  This usually includes the metrics that define it, as well as the people and systems that interact with it.  I also like to highlight areas where we can see obvious improvements and areas that we can't touch due to some dependency.  This fits nicely into a PowerPoint deck – and you can add more descriptions within the notes.  Hey, if you have a workflow tool that you can mock something up with, that’d be great too.

This gives a more visually engaging description of the process that anyone can follow and understand.

As an aside, on a number of occasions this type of documentation has led to useful feedback as to why certain steps within the process exist, which weren’t captured in the initial analysis. Sometimes this leads to nothing much, but every now and then it can be quite useful.

Target audiences for this type of analysis can be quite varied.  For me, this leads to a variety of documents as part of my deliverables:

• Functional documents – describing the systems involved, dependencies of the process and actors involved.
• Flow charts for the internal team - to help with the project plan and tasks;
• PowerPoint Story boards for the stakeholders within the process - to visually describe how they work in the hope it inspires further dialogue down the line on things I may have missed or misunderstood.

It’s in the Story Board that I wish to get the most out of.  It is here where the true value of the analysis can be seen.  The idea of trying to engage the people involved in the process to introduce any findings that I may have overlooked.  If I’ve done a good enough job with this document, I can feel comfortable that I know all I need to know heading into my “To-be” design.

Making a change

If we skip the "As-is" analysis, we make it all the more difficult to create a Change Management strategy.  If we don't know what we are taking away from the people involved in the process, it makes it more difficult to highlight how we are making the process better/cheaper/faster. 

We can't tell the people involved how this will impact them directly and indirectly.  Depending on the size of the process and the people involved, this can be quite a critical step in the adoption of the process.  Whilst it's simple enough to say: we're implementing this, so they must use it.  It is not always the case. 

If we implement it, and enough people resist it, then chances are it will be abandoned.  People will either go back to the way it was, or find a way to work-around this shiny new system to suit their needs better and then we’re back where we started. 

The project may initially be seen as a success, and us, as consultants, may walk away smiling, but if our ultimate goal was to ensure client satisfaction, and hopefully repeat work, we need to make sure that the process we’ve implemented sticks.  That it has a certain longevity within the organisation.  A strong Change Management plan can help with this.  And a strong Change Management plan comes from understanding what has changed and to whom.  And this requires an “As-is” analysis.

Dramatic conclusion

By the end of the project, if you've successfully completed an As-is analysis you should be able to:

• Compare your measurements between the old process (As-is) and current process (To-be);
• Bringing the people involved in the process on-board as you move from current to new;
• Get to know the industry, the business and the people within the business;
• Make a plan to transition people from the old process (As-is) to the new process (To-be).

When we start a project, we start by asking the Stakeholders, what do you want to get out of this project?

At the end of the project, we want to show the Stakeholders that we listened to what they wanted, and we delivered it.  This is what you had.  This is what you've got.  We can show the reasons why the new process is an improvement on the old.  We can show them how the people on the ground will adopt and use the new process.  They're happy, we're happy and hopefully we’ll be back to help them adapt to the ever-changing environment in the future.

Story Boarding the Business Process

Example of a Story Board

How to highlight, within an As-is presentation, areas to improve a process ready for a To-be process design

If you didn't read my previous post, have a look at: Communicating a business process

The idea behind the Story Board is to quickly introduce all the teams or roles involved in the process we are trying to define and later improve. We want the document to be something that requires little upfront introductions and allows people to quickly get a feel as to what we are trying to do.

As we introduce new slides to the process, we can colour code the images with a Green, Red or Yellow.
The boarders of Red, Green and Yellow describe slides that we have highlighted as: Green = Understood; Yellow = Need clarification; Red = Need more details.
In this example of a very simple On Boarding Process we can quickly show someone - be it Stakeholder, Manager, End-User, person walking in off the street - the process of on boarding a new person, and they should be able to follow it and understand the current process without much introduction to what they are seeing.
We can then begin the next phase of our process improvement steps by designing a To-be process once we have clarified the parts within the existing process that we don't quite understand in full.
The idea behind doing this is quite simple. We wish the As-is process to elicit further conversation amongst the people involved in the process. We want them to highlight where we have misunderstood the importance of something. Or where we have missed a vital step in the process. We also want the business to see for themselves where they are being inefficient and why we wish to improve their current process.

In the next post I'll talk about the importance of the As-is process. This is something that oft-times is misunderstood. The step of describing how they work today is vital in understanding how we can best change the behaviours of the people involved in the process.
Once we have properly defined the As-is Process, we'll want to Story Board the To-be process for similar reasons. To elicit further discussion amongst our business users to ensure that we capture all the relevant events and to ensure we cater for the majority of their business process requirements. We want as much involvement from our business users in modelling the T-be process so as to increase the likelihood of a smooth adoption to the new process.
Swim lanes and Flow Chart diagrams in Visio are good, even great. I would still be drawing those up for more detail. But their target audience is restricted to those that understand them and are often ignored by business users who have better things to do with their time. Story Boards tend to get more eyeballs watch over them and, in the end, that is what we are looking for.

Communicating a Business Process Solution

In a typical Business Process Solution project there will be a number of key members of the Project Team.  These might include a: Project Manager; Information Architect; Business Analyst; Solution Architect; Technical Architect; and the Development Team.  Their might also be key stakeholders such as a: CIO; IT Manager; System Administrator; and business users who may be directly involved in process itself.

These team members might come and go throughout the project and might not necessarily be full time in the project in the first instance.  Given that, how do we communicate the business process in such a way that the various levels of the project team, both the technical and non-technical alike  - not all of whom are on the project at all times – can quickly and/or easily be brought up to speed on the business process solution?

Let’s take a step back and understand the described Project Team:

·     Key Stakeholder(s) (Non-technical): Their interest is along the same lines as the Project Manager.  They want to see the Return on Investment promised to them.  Their interests in a Business Process Solution? Budget, time estimates, ROI.

·     Project Manager (Non-technical): in IT projects in general, PM’s usually come from an IT background at some point in time.  They might not understand the very technical elements of a solution; however they are generally IT savvy.  But what are their interests in a Business Process Solution?  Budget, scope, resources, time estimates.

·     Information Architect (Non-technical): bridges the gaps between the business, the information consumed, and how that data is utilized (governance plan) through the Business Process Solution.  Their interests in a Business Process Solution? Content or structures, governance of content.

·     Business Analyst (Non-technical): the face of the business user, they not only gather requirements but validate and verify those requirements.   This ensures that when this is communicated to the Technical Team, it is done so in a consistent way.   Their interests in a Business Process Solution? Requirements gathering - both business and functional.

·    Solution Architect (Technical): following on from the SOA and SOE and along with the information received from the Information Architect, to design a technology stack that confirms the business and functional requirements.  Their interests in a Business Process Solution? Solution design conforms to existing architecture models defined at the enterprise level, systems.

·    Technical Architect (Technical): creates the framework that will allow for the implementation of the solution design at a task based level.  Their interests in a Business Process Solution? Technologies, Tasks and systems.

·    Developers (Technical): purely technical, they follow the framework and complete the assigned tasks validated by unit tests.  These tests will also include some functional tests to meet the requirements gathered by the Business Analyst which will have been translated into test cases by the Technical Architect.  Their interests in a Business Process Solution? Test cases and tasks.

·    Business Users (Non-technical): these are the users that will be affected most by the Business Process Solution.  They will have described their duties to the Business Analyst.  Their interests in a Business Process Solution?  That they get what they asked for.

Imagine these types of people in terms of Levels.  Each Level of Person has a different agenda within the Project Team.  Given these diverse roles and responsibilities of the people within the team, how can we document the Business Process Solution in a way that each member(s) of the team understands what is being delivered.  How do we ensure that everyone is on the same page, when each of the Levels has very different interest or focus within the solution?

Before you jump to the conclusion: “well you just write a document at each level” – consider this: if each of the various team members wrote a document – who is the target audience of that document?  Essentially it is the Level below them in the chain.   If you’ve ever played the game Chinese Whispers, the more times someone passes what they heard to someone else etc; by the time it gets back around to the originator of the message, it generally sounds like something else.

You might then argue that: “we’re writing and not speaking; and we’re reading and not listening; therefore the above statement is mute”.  However, you can describe the above in terms of translation; each team Level reads the document passed down to them, and translates it into a document targeted for the Level below them.  Each translation changes the original description to the point that when it is presented back, it generally sounds like something else… sound familiar.

Example: I want something that has four wheels; a steering wheel; a seat; an engine; uses petrol… and they were describing a lawn mower. 

Example: There’s a similar one about the radio/iPod etc.  What’s this got to do with the Business Process Solution?

Back on point, how do we currently document business process?  There’s quite a number of ways – BMPN (Business Process Management Notation) diagrams; swim lane diagrams using software such as Visio; UML diagrams…. These are great for the Business Analyst to describe to the Solution and/or Technical Architects; but what about to: the Business User; or the CIO; or the Project Manager.  They don’t really care about interpreting the curved edge activity with an arrowed line adjoining it.

Information Architects might throw in a data flow diagram or something similar; Solution Architects will draw a type of technology stack diagram depicting the communication boundaries of each layer; and so on. 

How do we ensure that all these documents are being interpreted the same way?  Solving this question will go a long way in making a successful Business Process Solution.  An abstracted document containing parts of each Level within it would be a pointless exercise – no one would read it.  Pictures speak a thousand words, but just looking at a picture can leave too much to the imagination – does a picture of the Eiffel Tower let you know I’m talking about: amazing constructions; France; or Holiday Tours?  Maybe I was talking about screen resolution and the Eiffel Tower itself actually didn’t mean anything at all.

The answer I give to this problem, which I find works very well for Business Process Solutions, is: Story Boards.  Often a technique used for Web Sites and User Interface designs, this works well for Business Process as well.  

They can then be translated well into UML diagrams; they can describe a technology stack; they can describe the Actors (or end users); It can describe where the Return of Investment is, by highlighting key areas of improvement from the old process to the new process; It can highlight gaps where a new implementation has to be created and where we are piggy backing on legacy systems;  they can show how the data moves from one system to another and which user(s) are in control of that data; User stories and use cases are also a natural progression from here; most importantly, they can grow and shrink throughout the lifecycle of the project.

How?

How do we use the story board to do this?

Return of Investment:

Draw the current story and start colour coding the border of each story board can quickly show or highlight key stories that show how the process has improved.  Red, green, amber.  Red for things that are creating bottlenecks in the process; green for things we’ve improved or added to reduce the process, and amber for the status quo.

Then draw the new story and walk through this process in the same fashion highlighting again where the value-add is.  Before versus after images paint a very clear image to the key stakeholders of how and where they are going to see the improvements.  Even if they don’t go any further than this in the project, this still gives them value.  It shows where they are being inefficient, and how they can streamline their processes, if not now, in the future.

Budget/Time:

This goes to the core of the project and interests both the PM and the Stakeholders of the project.  When will this be delivered, and how much will it cost.  By highlighting very clearly and distinctly where the changes are occurring, we can then focus our attention on these types of matters.  Lots of green story boards would represent a lot of change, which in theory could represent lots of work.  Therefore more resources, budget and time required.

Content and Structures:

Defining the structure and the content of the story is key.  If we think about it in terms of a movie, the Information Architect would be providing the words coming out of the Actors mouth.  Or, in the case of a Business Process Solution, the information flowing from: the system; to the end user (or Actor); and back.  The story boards can move from an image of the Help Desk Actor staring at his computer as a new message comes in; and the next image can be the message itself as we imagine the Help Desk Actor reading it.

Technologies:

The Solution Architect can then provide the background descriptions on the Story Board, describing which technology the Help Desk Actor is using to see the message coming in: SharePoint 2010 through a K2 Worklist WebPart; and in the next image, using Outlook to open the email.

Tasks:

The Technical Architect can then provide the notes at the bottom of the Story Board describing the type of development or change needed to implement the technologies described in the story.

With all this, we can then walk both the Key Stakeholders and the general Business Users affected by the new process definition; and describe this in a simple and clear way.  It is at a level of abstract enough that it cuts through each of the levels of the Project Team.  They can then go and create their normal documents, but they can now do it with a common understanding of what they are describing; the person reading the document can then review it with a common understanding of what they are reading.  When you have a story that combines the picture with the description, it becomes a very powerful tool.  Handing this project over to the Change Management Team or a new Project Team member is also made simpler.  They don’t have to read streams of documents across the Levels, just read the before and after story boards and they are up to speed.

The Business User, who just wants what they asked for, well they still might not get it.  Budget, time, scope, resources and technologies will all contribute to them having to forgo something.  But chances are the project will go smoother, and if the communication lines are direct and often enough between the Technical Team and the Business Team, then they at least won’t be disappointed.  Henry Ford once said, “If I had asked people what they wanted, they would have said faster horses”… hopefully by documenting in this way before starting development, you’ll be able to deliver the car, and not another type of horse.

How to setup the Story Board:

I won’t go into the “before” story as this can be done in a similar way, this will just go through the “after” story.  The technology you use to present the story is completely up to you.  PowerPoint is a simple way, but you may have other tools that will do something better.

Actors: Start with the Key Actors… Just like they do in the movies, we do here.  Start with the Actors that this Story is mainly about.  If it’s across the organisation, then start with the big named ones.

Starring:

·         Human Resources;

·         Help Desk;

·         Middle Management; with 
·         Asset Management; and 
·         New Employee; 

Project Title: Give the Project a name if it doesn’t already have one. 

Presents:

·         The On Boarding Process

Story Board One: Give each story board a name.  This is something that can be used as a reference point from here on in.

          The Initiation:

·         Border Colour: Amber

·         Boxed Caption: Commencing the On Boarding Process through SAP system;

·         Picture: Two people shaking hands in an office;

·         Talk Caption: Person on the right: Congrats Bill, you’re hired for the position of Analyst, and will report to Joseph on Monday.

·         Notes Caption: Person’s name; position; manager; start date; SAP HR Form; Office access area; induction material;

Story Board Two:

           Initiation Form Details

·         Border Colour: Amber

·         Boxed Caption: SAP HR Form; SAP Database;

·         Picture: Wireframe of a SAP system Form with the fields to fill out being:

o   Person’s name: Bill Bilson;

o   Position: Analyst;

o   Start Date: Monday, 1^st February 2026;

o   Manager: Joseph Johnson;

o   Office Access Area: Level 1, Desk 286;

·         Talk Caption: Human Resources filling out SAP HR Form raised through Portal;

·         Notes Caption: SAP Form Details; Data stored in SAP;

Story Board Three:

Birth of Bill Bilson

·         Border Colour: Green;

·         Boxed Caption: SAP Database; K2 Workflow Process;

·         Picture: Database Server Cluster showing the SAP Database(s); typical K2 View Flow diagram depicting a workflow process.

·         Talk Caption: SAP informs the On Boarding Workflow Process to begin by passing the UserID for Bill.

·         Notes Caption: SAP Database; K2 Connect Event occurs; K2 Workflow process launch; User ID and Process ID captured and stored; K2 SmartObject storing these details;

Story Board Four:

Notify Help Desk

·         Border Colour: Green

·         Boxed Caption: K2 Worklist Task;

·         Picture: Help Desk Office with a group of users sitting at their desks, looking at their computers.

·         Talk Caption: I have a new task to do today; Looks like Bill Bilson needs a new Network Account created.

·         Notes Caption: Active Directory account creation; Email account creation; added to appropriate AD groups and Distribution Lists based on his role and position;

Story Board Five:

Create the Account

·         Border Colour: Red;

·         Boxed Caption: Add user to Active Directory; Add user to Exchange; Add users to AD Groups; Add user to Network Drives and other key source systems;

·         Picture: Four different source system data input screens; Source System (SS) 1 in top left, SS2 in top right; SS3 in bottom left; SS4 in bottom right: Ie.  |+|

·         Talk Caption: I need his: name, position; office location; and his manager to create this person in our systems;

·         Notes: Manual step that the Help Desk Person does; Closes the K2 Worklist Task once completed;

Story Board Six:

           Get some Hardware

·         Border Colour: Green

·         Boxed Caption: K2 Workflow Process; Asset Management Process;

·         Picture: Person dressed in blue overalls and yellow hat, picking up a box in a warehouse style Store Room filled with boxes and levels;

·         Talk Caption: Looks like I have an order for: a laptop (#236A); mouse (#237A); monitor (#238A); mobile phone (#987Z); IP Phone (#986Z) for User ID: #23;

·         Notes: Email notification sent to Asset Management Team; Assigns User ID to Hardware Asset Number through system integration;

… and so on…

I hope this is enough information to get the point across.  We can quickly see here where we are improving the system (through the Green slides: #3; #4; and #6); where we are continuing on with the current system (Amber – and we can look at ways to improve: #1; and #2); where we aren’t really providing anything that will improve the system, and at the same time potentially causing a bottle neck (Red Slides: #5).

Let’s look a little closely then at slide 5.  Certainly this would draw attention at the meeting room and would require further explanation.  Why is this slide Red? 

It’s the colour Red because it is manual.  It currently requires the Help Desk person to read the information coming from one system, and type it into another system(s).  There’s risk that they neglect to add the user to any one of the other source system cause Bill Bilson to come into work on Monday and not be productive.  It’s also Red because the information has already been collected and entered into a source system – SAP.  So why should we need to enter it manually into other source systems at all from that point onwards?  There would surely be valid answers to these types of questions: lack of resources available to extract information from SAP and auto-generate an AD Account or a DMS Account or to a specific location(s) in the Portal etc.     

We highlight it Red so that we know that this is an area that we can improve upon in the future.  It becomes something that everyone can quickly see and understand.  It can be a way of highlighting how the process did something similar at the Asset Management step, to show that it is possible.  How we’ve sync’d the data from SAP through the Workflow down to the source system and commenced the process of getting the user: Bill, set up for Monday with everything he needs; whilst also enabling the Asset Manager to see that User ID #23 has assets: #236A; #237A; #238A; #987Z; and #986Z; with the only human step being to physically deliver the hardware.

You might need more story boards, you might need less, but what this gives you is that distinguishable story that everyone across the various levels can understand and discuss.  From the very technical to the complete opposite of very technical… you still need the: Design Doc; Tech Spec; User Stories; Use Cases; Test Cases; and head cases to make it work.  For me, the story board exercise in a Business Process Solution is the missing link, and needs to start being the consistent link.

Post Go-Live Strategy

What happens after you have completed the application lifecycle of a Business Process and implemented the solution?

You’ve launched the workflow and the organisation have signed off and gone live with your masterpiece.  It’s a work of art.  You couldn’t be happier.  The Business Analysis Team was switched on; your key users were involved throughout the lifecycle; the stakeholders are counting how much money they’ll save with this magnificent piece of work you have created.

What’s your next move?  Is it to go on to the next project?  Have you thought about your post Go-Live strategy?  If you’re not following me yet, then we’re probably not as good as we were looking in the above paragraph.  If you are following me and you think you’re still moving on to the next project straight after, then we’re still not looking as good as we were in the above paragraph. 

If you’re next move was to implement any of the following: 

• a “Continuous Improvement Register”– something that will enable users to add “nice to haves”, “should haves”, “must haves” for your process;
• a support strategy – known issues list of what typically might go wrong with your process and how to quickly resolve it; which will be maintained by the support team;
• a maintenance strategy – a way for the owner of the application to see both the Continuous Improvement and Known Issues list that will enable them to see how they can ensure that the business adapts to the process, and that the process can adapt to the business.

These things are critical to the overall success of the application.  You’ve just put all your blood, sweat and tears into a Business Process, the last thing you’d want to see is that in six months’ time, the business has outgrown your process.  They are critical strategies; there should be no doubt about it.  Yet it doesn’t seem to be obvious to everyone in the projects that I’m involved in.  It seems to follow me around, this constant discussion and/or battle that these things should also be part of the application lifecycle planning and budget.

This goes beyond just your usual: Quick Reference Guides; user training; and handover notes or walk throughs.   Businesses change how they do things constantly.  With every change in personnel, or systems or the policies that organisations put in place, your Business Process Model needs to change with it.  The only way it can do that is to constantly capture these changes.  Encourage users and support teams to capture (or capture it for them) these and then react to the change.

Even a great process will still have a limited shelf life.  It might be three months, it might be a year, it might be longer, but it will eventually become out-dated.  If it doesn’t, you’re either not looking, or the users have worked out ways to “get around” the limitations of your once perfect process.  All of a sudden, those pretty pennies that the stakeholders thought they had saved have now turned into pieces of paper with “IOU” written on them. 

Application Lifecycle: gather requirements; specify functionality; design solution; build solution; accept solution; implement solution; strategy to support solution; strategy to maintain solution;

Let’s stop the battle, let’s all just agree with me on this, that the process isn’t complete after Go-Live.  The process grows (more integration with systems, more automation, more data capture, more reporting capabilities) and shrinks (less approval steps, less human validation steps, less bottle necks) with the business.  Let’s start planning in our projects that this is a key element that needs time and budget.  It’s not tacked on to the existing budget; it’s carefully and strategically placed as part of the budget.   Whilst you, the K2 Expert, won’t have to be there to support or to necessarily maintain the process, the strategy for both should be part of your responsibilities. 

The planning of these strategies occurs at the design and doesn’t stop… ever.  So start asking the questions: how do we support it; how do we maintain it; how do we ensure its longevity?  If these are taken seriously at the start of the project, then your Business Process Model will remain as perfect as it was when you first released it into the wild, otherwise... I’m all talked out about otherwise…