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.

How a junior staff member can review the work of his senior

Jedi Master and ApprenticeA story

There is a small team of 4 developers. These guys are very different from each other.

John is experienced and worked for more than 15 years with the company in different roles. His mantra is “never change a working approach”. He preservers the status quo.

William has the same level of experience in the company but has developed a love for the latest “best practices”. He is always on the look out how to improve things.

Mary is with the company just for a few years and then fresh from University. Some of the “old stuff” she is dealing with is hurting her sense of “doing it right” albeit she acknowledges it works. Refactoring would make maintenance and support easier but would have no visible benefit for the end user.

Alan joins the team and it is his first job. He likes the solid and calm approach from John, the energy from William who always seem to find a way to make stuff better for the customer, and the quick thinking Mary who knows tech stuff in and out.

The team leader struggles at times to get them working together effectively. 2 pairs emerge initially, William and Mary driving change with John and Alan asking, isn’t it working fine? Both have very valid points and the team leader would love to get more synergy going and not risking confrontation between the pairs.

Several approaches come to his mind and he settles on breaking the pairs up by switching the 2 younger members around. To get the learning going he asks the pairs to review their work. One of the older guys, John, has a problem with that as he feels Mary being “too cocky” about the old and well proven way he does things.

The team leader remembers a story he heard once how an airline handled a similar challenge. He takes John and William for a walk and explains to them the idea. He asks them to purposely insert some mistakes in their code. That way there is no loss of face, even if the younger guys find things that were made accidentally. He also tells the younger guys so they know there is no conflict between reviewing code and not making friends with team mates.

This approach can be refined to address the different ways of coding, create appreciation of a new way of doing things as well as proven methods.

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?

 

4 principles of Information Management

Variety - Volume - Velocity

Variety – Volume – Velocity

The world of big data arrived some time ago. And while the amount of information on the Net is continuously rising, it happens on our personal and corporate systems, too. One only needs to look at the emergence of products like “Sanebox“, which helps you manage your email inbox, cloud storage and share systems like Dropbox and Box, and the rapidly rising capacity that Amazon provides with S3.

Every one of us has so much information available that it becomes harder to keep track of what’s important and how to find it again 2 weeks later!

Good Information Management starts with recognising that is necessary to do something about it.

People

This leads us straight to the first principle. Employees need to do Information Management and not just acknowledging it is a good thing. Hence we must put things in place that ensure people act and act consistently.

Process

This is supported by well designed processes. For example, a supplier email comes in advising a new pricelist. Who receives the email? Is it documented where the new pricelist is stored? Are relevant people notified? Is the old pricelist replaced or marked as obsolete? What happens if the email recipient has left the company?

Content

Information Management is about content. Recognise the different types of information from Word documents, to emails and phone call, from drafts to published data, or from project management to customer requests. Create categories that are relevant to your business and link those to your processes.

Technology

Okay, I’m in IT so let’s not forget that the tools you use play a role, too. Where do people store information? On the local harddrives, a shared service, the cloud? Consistently in the same folders or directories? A lot of people use their email system for storage and retrieval. Most email systems have quite good search capabilities while finding a much needed document on a shared drive or even your local computer is often a challenge. Choose technology that does what you want and is aligned how your staff works.

 

 

Don’t compromise!

dont_compromiseSome time ago I finished reading “Steve Jobbs”. A number of things “resonated” with me while others don’t. Some, I find simply disturbing. Then there is one item where I’m sitting on the fence.

Don’t Compromise.

The absolute belief

  • that there are no trade offs that can’t be cast away,
  • that there is always a way to get exactly what I want and to ignore the counsel of others

Continue reading