Projects, Processes, and People

Photo by Marcelo Braga, licensed under Creative Commons 2.0.

Today, I experienced an interesting discussion and later this evening I read three related articles. That all came together more or less incidentally.

At work we are going through a restructure phase and one team had a coffee to discuss what it meant for them. In general, the people were concerned about the lack of detail, what the change meant for them personally and how “it” was going to work.

I don’t actually need to go into the details who the team was and what they currently do, it is immaterial. Not one team member was or is a change agent, not one was able to translate the strategic vision into something tangible.

Later I came across these 2 articles:

First, a blog post from 99U published in April 2014:

he Difference Between Projects and Processes:

Projects create change. Processes resist change.

Wow, so obvious and still – I forgot about it at the discussion. The people are used to work in a particular way, they are used that someone is responsible for this, then another person does that, and finally a third one completes the task. Quite obviously the new structure is meant to break that. Its objective is to create, to force change. That’s not going to happen if processes stay the same. Hence implementing the new structure must be treated as a project.

And that’s where the second article comes in. This one published by the Smashing Magazine in July 2013:

People > Projects > Processes:

Having a process is good, but be careful that it does not overshadow the project itself or the people involved.

Processes are good to get the same quality every time. The ISO 9000 family is designed to do just that.

Projects are meant to create new processes or make existing ones better. And often they rely on processes themselves (PMI or Prince2 anyone?).

And what is the most important asset any organisation has? Its people. What is in the top 5 most important things organisations try to improve on? Employee Engagement. Why do projects fail? In 72% of all cases it is a communication breakdown.

Summary

Coming back to our discussion. Yes, I failed to appreciate the disruptive value of the restructure. But also, uncertainty about mapping the vision to the structure on middle management level means learning by making mistakes in creating new processes for the same business objectives must be acceptable. Disruption to existing support processes and delays in delivering functional projects may also occur. All under the vision of creating a better service in the near future.

You gotta break some eggs to make an omelette.

A Process Guide

Librarian, the Original Search EngineIn the world of Information Management we encounter a lot of different types of data. In order to get the most value an organisation (or individual) would need to know what is perceived as valuable. And also, how the value is realised.

For example, recently Tesla announced making their priced intellectual property available to the public. That is a change in the business thinking of perceived value from keeping the information secret to stay ahead of the pack to sharing the information to innovate faster and create momentum.

My process guide includes these questions:

  • WHAT to document?
    Not everything has value, identify it and exclude it from being treated as such. Simplify the management of non-value items.
  • WHERE to save or publish
    First, understand the difference between a simple “save” = making sure the document is recoverable and a different concept “publish” = making information available for consumption by others. Second, have rules or guidelines where such artefacts are physically located. This can range from your local hard-drive, file servers, dedicated cloud services, to document or record management systems. You decide but spell it out.
  • HOW to document
    This looks like a trivial idea, it is not. The level of detail may make a difference for regulatory information compared to a customer record. One must have certain details to ensure compliance, while the other may be okay with only some meta data relative to the current conversation.
  • HOW to version
    luckily many systems have version control build in – see document management systems in Wikipedia. However, there are still plenty applications that do not. Email is first on that list.
  • HOW to share
    You may ask, what’s the problem? We access the same file on the file server / cloud service / etc. And external people get a copy by email or memory stick. The distribution of uncontrolled copies is enemy no. 1 for Information Management. You will never know who still got the old copy with the incorrect pricing information in chapter 5.
  • HOW to manage access
    Having mastered a better sharing solution, you will find another stepping stones along the way. The best way to manage access. 2 different schools of thought exists – (1) everything is open and only special items are secured. (2) everything is closed and access is granted where needed. Option (1) is common in internal networks and (2) in extranets.
  • WHAT is the change process
    2 core change processes exist. (1) how becomes a saved artefact published? Are there stop gaps, control mechanism, approval workflows, or gatekeepers involved? (2) how is a published artefact updated? And in particular how are stakeholders notified?

I hope those few ideas are helping to get some discussion going!

—–

Note, the above image is taken from this blog advertising a role as Librarian in 2013. I recommend reading it 🙂

Why should I do Information Management?

Wanted! people that follow processes

Wanted! people that follow processes

In my previous post I highlighted the 4 corner stones of good Information Management.

  • people
  • processes
  • content and
  • technology

Today, I want to add more detail on the people section. You can have the most clever system and still nobody cares. That would be worst case scenario. How can we pave the way for being successful on this front?

User Experience

About 10 years ago I was the first time involved in Document Management. A small team having experts from the different business areas designed the requirements. A large 20 page document outlined all meta data we could think of, structured in categories and divided into mandatory and optional items. We presented this to a selected group of people with devastating result. It failed the 7 second filing test.

One guy said, “if it takes me longer than 7 seconds to file a document with all this extra data, I won’t do it. I’ll use my trusted filing system where I know exactly where my documents are. Others are most welcome to follow the same process.”

These few sentences highlighted common problems with projects, that were not designed with the user in mind but with a process or an ideal outcome. In this case, all documents would be perfectly tagged with relevant meta data and a process would take care of that.

Lessons learnt:

  • any system must be at least as good as the existing system
  • any trade offs must be clearly understood and accepted
  • and the system must be designed for excellent user experience

Is UX sufficient?

The answer is likely to find in this quote:

Any information system is only as good as it is being used.

Tell me, what else can you do that people use the system?