Avoid creating more Corporate Debris

It would probably not take you long to look through the records of any organisation and find some items, probably lots of items, that are Corporate Debris.

There are two types of debris left behind by projects, specifically by Process Projects;

  1. Process models, descriptions, requirements, design, strategy and good intention that have never been utilised, and
  2. Previous versions of the above artefacts that have been replaced or updated; however the original versions are still being used or are accessible within the organisation.

I have seen too many examples of enthusiastic projects that have created a new process, procedure or strategy that has not been adopted or sustained in the business after the project has been completed. I had one experience where I was shown a department’s “Process Library”. It was sitting in a series of well presented folders in a small cupboard in the Directors office – that’s as far as the project had got to real change.

The best case scenario is that a lot of money is wasted as the project has clearly not achieved it’s outcomes; however the more common worst case is that the opportunity lost is followed up by disappointment and scepticism that a process project can never be successful.

The end users are often victims of corporate debris as they find various versions of “the truth” in knowledge libraries and they struggle with which processes or work instructions they are meant to be following. If there is a renewed attempt to improve the process, they will often start from step one because no-one is sure which of the previous versions of analysis to use and just how correct were they?

At the 2009 Process Days conference I sat on a panel that discussed the value of Process Modelling. My contribution was to state that process modelling was only valuable if creating the models generated share understanding and the result was actually going to be used. I asked for our process models to be living.

I wish I had found this George Box quote last year, “All models are wrong, some are useful”.

How to build “living process models”

There are a number of simple Information Management principles that should be applied to organisational information like;

  • Recognise corporate information and manage it’s lifecycle – Creation to Removal
  • Be ruthless – Just because it is stored electronically, it doesn’t mean you can ignore it!
  • If it is important corporate information – hold someone accountable for managing it!

    There is much more that goes into an Information Management strategy; however that’s another Business Process for another article!

    A living process model is a representation of your Business Process that is constantly referred to and updated by the people who are living and breathing the process. If I ask anyone who is involved in the process what documentation are they using to guide their work; I should always be pointed to an artefact that is linked to the current Business Process model.

    Keeping Process Models up-to-date is often an issue. The workers are not going to maintain the process information if an update involves a 12-week review cycle. Imagine a world where the living process can be updated within 1 day, with 1 reviewer!

    There are 2 keys things that are needed to achieve living processes;

    1. A process modelling platform that allows you to publish the current process diagrams to everyone, with all of the relevant information relating to actually doing the process activities, and a process to keep it up to date.
    2. Adopting enterprise processes to design, share, improve, measure and be responsible for all living business processes.

    It sounds easy? What would you need to do to bring your business processes to life?

    Tagged , , , , , , . Bookmark the permalink.

    9 Responses to Avoid creating more Corporate Debris

    1. I agree with your comments. You could put these documents to the right of the SOA models, the object models, the data models, the reference implementations, etc. etc…
      Part of the issue that you allude to is in the ‘As-is’ and the ‘To-Be’ delusions. The idea that an organization should make a single shift to a static to-be contributes to the creation of this shelf-ware. A process should be evolving and recognition of these fleeting natures is important. The key is to create immediate value with the modeling, that is:

      1) Create true visibility, not a vision, but who does it, and what do they do and
      2) Accelerate alignment multi-organization functionality.

    2. Mike Gammage says:

      Craig,

      Brilliant term – ‘corporate debris’. Totally agree about the need for living process models, ‘constantly referred to and updated by the people who are living and breathing the process’. Anything less is a waste of time or opportunity (or both).

      But I can’t agree with Tom that the answer lies in SOA or any other IT-oriented models. They are essential but only one perspective. The enterprise needs a way to fuse the business and IT perspectives, to get a complete insight and stand a hope of synchronising in real time these two necessarily different views of the world.

      More on this on my blog for those interested: http://bit.ly/9P3mzh

      Mike

    3. @Tom Debevoise

      Thank Tom, I am not clear what you mean by putting document to “the right” of the other models. All models can become Corporate Debris – the output of IT projects even more so! I have often gone to support or improve an IT system only to find that if the related models exist, they are from the original implementation and have not been kept up to date as fixes and enhancements have been made. The same “living” principals apply – in fact they can be linked to the Business Process model that they support and everyone wins!

      I like the idea of “Visibility” rather than vision. Let’s make our model visible!

      Cheers
      Craig

    4. @Mike Gammage

      Thanks for the feedback Mike. I have added yours and Tom’s blogs to the list of Process Blogs on the site.

      I think the opportunity lost is the real issue. We could achieve so much more with Process Management if we can get the Process Owners to live the role and live their own models.

      I agree perspective is important, not just the Business versus IT, also the Strategic versus Operational. I recently saw an example of a process that management wanted to improve; however the people who breathed the process thought it was fine. Why? Because the process was done efficiently – It did not matter that it really did not add value, and the managers did not get what they wanted from it!

      Pretty common I bet!

      Cheers
      Craig

    5. Corporate Debris is a great term, I think I’ll steal it.

      One source of the issue of corporate debris w.r.t. process management is that there is no link between the process definition artifacts and the process execution. I don’t mean the full fledged completely detailed process model that supposedly generates the process managemet runtime – but the real world cases of documents in MS Office that contain procedures, guidelines and maybe a rough process model, that may or not be stored in a Document Management system.

      There needs to be awareness between those documents and process execution, and process execution and process definition documents. That way when I look at a process I can find the related documents that define process, and when I look at the documents I can see the process context.

      Jacob Ukelson – CTO ActionBase

    6. @Jacob Ukelson

      Go for it Jacob, I love to share!

      A key component of the “living process” model is to include the procedures (I like to call them work practices) that are actually done to complete each process activity. My preference is to actually store the work practices in the process model, so they are one and the same – not just a link to an independent document.

      If the work practices are embedded in the process model then process workers need to access the process to access the instructions, meaning that they are exposed to the process context (not just their own part of it) which I believe is important to achieving an efficient end-to-end process.

      Cheers
      Craig

    7. The way we do it at ActionBase is to link the procedure documents to actual execution instances. That enables us to show how a process instance is executing with respect to the docuemented procedure, overlayed on the actual procedure document

      Jacob Ukelson – CTO ActionBase

    8. Thanks Jacob, I will have a look at the papers on your site as I am planning to write up a summary of the application options for implementing living processes.

      Cheers
      Craig

    9. Jonathan Boyd says:

      Great article Craig, I too love the term “Corporate Debris”, you should trademark it!

      I believe the key issue or challenge with process modeling is the unfamiliarity of most business users and even analysts with how to do this and also the lack of availability of easy-to-use tools that are better than just using Visio or PowerPoint. This leads to incomplete and inaccurate business process documentation that quickly becomes out-of-date as you correctly say that these are not treated as “living process models”.

      Our team has been using the AccuProcess Modeler in the recent months and have found this to be a great tool which anyone can use without a lot of formal training. It includes process modeling, documentation and even process simulation for the as-is and to-be processes. It is available at: http://www.accuprocess.com

      This has helped our team to “own” the process information to ensure it is accurate and then update it regularly to treat them as living artifacts that are constantly up-to-date. I believe a tool that makes this possible is key to success.

      Thanks.

    Leave a Reply

    Your email address will not be published. Required fields are marked *