Navigating Technology Change

Everyone has their favorite GPS or “SatNav” story. It used to be a weekly occurrence, for example, to hear of large intercontinental trucks getting stuck down narrow country lanes in the south of England as European drivers used their SatNav systems to try to get to remote farms and businesses for the first time. This is the first Management of Change lesson for any IT department:

New technology used “blindly” out of the box without any practical guidance or best practices can often end up costing more than the old method.

In another example closer to home, I increasingly find myself at a loss when setting up informal meetings with potential vendors at local coffee shops or deli’s: Where I would normally assist with directions by providing instructions like “turn left and go for about half a mile. It’s on the right with the green and white awning”, I now end up having to supply the exact street name and number for the visitor to plug into their GPS device. More often than not, I don’t know those specifics and have to look them up or call. This brings up lesson #2:

New technology may make your life easier, but it may also incur additional effort or inconvenience for others.

The solution in both cases is to ensure that you consider the complete end-end business processes of not only the target organization, but also their internal and external partners, suppliers and customers. What is good for one organization may not be good for the broader relationship.

At the same time, organizations can also get so focused on the tool or technology itself that they forget about the need to also change the way in which the organization operates to take advantage of them. This brings me to lesson #3:

New technology used in old ways will rarely yield significant operational improvement.

This goes beyond providing training on the new technology. It requires a complete understanding of all contributions to the process and each organization’s business requirements. These requirements are often poorly defined or contradictory, and it becomes IT’s job to join the dots and fill in the gaps to create a consistent and holistic process that the new technology can support. In some cases, this may also require overcoming the internal politics of change with senior management.

New Technology release is relatively easy. Effective adoption is not. However, if the business process is allowed to lead the technology, and historical barriers from organization charts and governance models are removed, you will be able to map out the big improvements you’re looking for and reach the right destination.

Advertisement

The Magic Number 7 (Plus or Minus 2)

For years I wondered why so many things appeared in collections of 7 items. There are Snow White’s 7 Dwarfs, the 7 Deadly Sins, the 7 Wonders of the Ancient World, and the 7 Seas.

Nearer to home, local phone numbers have 7 digits, standard vehicle license plates have combinations of 7 or less letters and numbers (this is also true for most countries in the world), and of course there are 7 days in every week and 7 NFL players must be in the line of scrimmage for a legal formation. I even grew up near a town in southern England called Sevenoaks.

Then I learned about the principle disclosed by George Miller in 1956 that a person’s short-term memory span is approximately 7 items. That number increases for common items such as letters and digits, and drops to nearer 5 for more complex items such as long or unfamiliar words. Any more than that, and a person’s ability to remember any of the items drops off dramatically. So if designers wanted people to easily remember a group of items – be they dwarfs’ names in a children’s story, or a number for self-dial telephones – they kept to that limit.

Project and Program Managers can also make use of this principle by organizing their teams into “right-sized” groups, each one having a clear focus and responsibility. The scrum agile software development method, for example, suggests a team size of 7 ± 2 for any given sprint. More generally a team structure can be created based on 5 or less distinct groups of participants, each group having a different role and requiring different communication content and frequency from the Project or Program Manager:

The Core Team: This should have no more than 7 ± 2 members. Any more and the tendency to seek consensus will slow down decision-making. This team typically contains the key solution architects and change agents that collectively make the key decisions and drive the project forward. Its members are typically full-time on the project and accountable for its success.

The Extended Team: Many projects and programs are of such complexity that the Core team alone cannot contain deep enough knowledge of all the subject matter required to achieve its goals. Consequently a cross-functional virtual team of Subject Matter Experts and advisers is required with representatives from all impacted departments. Members of this Extended Team are brought in as required for specific issues, key reviews and checkpoints. Unlike the Core team, the Extended team members will typically have other day-to-day duties outside of the Project or Program.

The Implementation Team(s): These are the developers, testers, production, installation and support teams that make the output of the project a reality. Each should have a point person responsible for liaising with the Core team. If the project is large, use appropriate hierarchical structures to keep the number of direct Core team connections below the magic 7 ± 2. Otherwise the span of control starts becoming unwieldy.

Sponsors & Stakeholders: This team is often neglected when creating a project resource plan, but is absolutely essential to the success of it before, during and after project execution. This team requires regular high-level status reports and an awareness of key issues that may require their intervention (eg project resources, mass communications, etc). A good project dashboard will contain no more than 7 ± 2 categories of items to report.

Users: Last but by no means least, the eventual users of the output from a project – whether it’s a new software solution, a revised operating process or procedure, an organizational change, or all three – require targeted “what does it mean for me” communications that explain the impact of the project in terms of their specific jobs and roles. The magic number is used here to make sure that sufficiently small groups of Users are addressed such that the messages are meaningful to their work, and that the messages are delivered frequently enough to reinforce the message, but not so frequently that they lose their impact.

One notable group of items that exceeds this short-term memory span rule is the Ten Commandments. Perhaps that’s why so many people seem to be forgetting them in modern times?

The Jell-O cup PMO

Have you ever got frustrated at the kids opening a pack of Jell-O cups just enough to extract one item, then struggling to tear back the pack a little more a day or so later for the next one? Or how about eating the last granola bar and leaving the empty box on the shelf so no-one knows to buy more? I know every parent turns off at least one light switch a day in the playroom or garage.

Process Transparency

As parents we often take on the responsibility of cleaning up these little items by taking the 30 seconds it requires to toss the boxes in the trash and add it to the grocery list, or by tearing the complete Jell-O package apart and placing all the cups loose back in the fridge. It makes life easier for everyone. However, if done properly, no-one realizes it’s being done – they just go right ahead and get the Jell-O or granola bar.

It’s part of our make-up as parents. Just like driving the family on vacation, or cleaning out the Guest Bedroom before Grandma comes to stay.

So it is with an effective PMO – the tools, processes and procedures it puts in place should be transparent to the normal operation of the organization. If they’re too “heavyweight” they will burden the core activities being performed. Too lightweight and they will leave too much to chance and never achieve their goals.

Getting a process wrong will also – at best – be wasteful of everyone’s time and energy, never a good thing in today’s resource constrained business environment. At worst it will cause people to find workarounds or avoid doing certain process steps at all, which creates inconsistency and variation in execution – the single biggest cause in operational waste according to disciples of Six Sigma.

It takes more than education

There also comes a point in any parent’s life when they decide it’s time to educate the rest of the family on proper refrigerator etiquette or energy saving. So we sit everyone down and explain. Younger ones nod. Teenagers roll their eyes. Everyone agrees to try to do better. However, several days later – weeks if you’re lucky – you’ll feel the need to sit them down again because it just didn’t seem to stick. And so it goes on over a lifetime until those kids have houses, mortgages and grocery bills of their own.

Only then do parents become smart.

On occasion, though, parents get a break: Consider when someone (probably a parent) at a soda can producer looked at how people use and store their products and discovered that if they laid the cans down in a box on their side rather than on end, and provided a tear-off corner for the box, they could create a little bit of storage excellence for families – the Refrigerator Pack.

Embedded Tools & Documentation

The lesson here for effective PMOs is that you can’t rely on process education alone. People forget, particularly if they use the tool or process infrequently. Instead, any tool has to be embedded completely in the process such that the task is made easier by its use and that it can’t be completed without it.

Process Documentation also has to be inherent in the tool or process itself, both at an overview and step-specific details. This can be done by using on-line Workflow maps which guide the user through key steps and provide easy access to specific Best Practice examples and how-to’s, or by building reusable templates and check lists that form the basis of the required project plans, process activities or data collection.

Just like the Refrigerator Pack, the PMO infrastructure needs to provide easy visibility to people’s use of it including the status of each item and overall flow through each process, and creates enough structure to ensure proper usage, yet enough flexibility to allow innovation and improvement in the process as the environment grows and changes.

Hopefully that’s some more Food for Thought (all be it Jell-O and Granola bars) to consider when creating your PMO.