Changing a Culture happens one tiny procedure at a time

Whenever I am involved in the deployment of an enterprise-wide system I’m reminded of an analogy attributed to Buckminster Fuller (You remember Bucky. He’s the fellow who came up with the idea of geodesic domes.) Anyway, the story is about turning a ship. You see, when a ship is very large, say the size of a super-tanker, the size of the rudder to turn it must be correspondingly large. The problem is, that a ship such as this underway causes so much water pressure on the rudder, that the force required to push it against the water to turn the ship is incredibly large. So, someone very clever invented the “trim-tab” A trim-tab is a little rudder on the rudder and it seems that if you push that rudder in the opposite direction you want to go, the main rudder can be moved outwards with almost no effort at all.

Ok, cute story, but what does it have to do with project management software and enterprise systems? Well, everything.

The biggest issue with deploying an enterprise system is not the perfect selection of functions against requirements, it’s changing the corporate culture. For anyone working in a medium to large sized organization, you know that comparing the intractability of a corporate culture to the momentum of a supertanker is not at all inappropriate.

Over the past few years I have seen many, many fine individuals break their spirit over this issue. They know they’ve picked a product that will answer their firm’s needs but are unable to get it implemented throughout the organization. No matter how much force they mustered, it was never enough to ‘turn the ship’. The selected software ends up either completely abandoned or being used just by the core implementation team, another element to add to a fractured systems environment.

In those organizations where an enterprise project control system has been successfully implemented, inevitably, the corporate culture was changed a step at at time.

Operational procedures are business’s ‘trim tabs’ for corporate change. Now, lest you leap forward and think, ‘Great, tomorrow I’ll get started on a new procedures manual with hundreds of procedures to make people comply with our new corporate culture.’ or that you think you can mandate a corporate culture change by simply making a procedure called “change your cultural habits”, think again.

The changes that will be most effective will be insidious yet impactful. I was recently privileged to be in a conference session with a number of experts in the deployment of enterprise-wide project systems. A couple of their comments are worth noting. One of these experts described how their organization had designed a “knowledge base” of lessons learned on past projects. For some time the knowledge base had been established yet no one ever seemed to have the time to contribute to it. If there were lessons being learned, they weren’t being made available to future project managers.

The expert in this organization (you’d recognize this three-letter firm if I mentioned it), decided on a small change in procedure. Inside the contract for the project management consultants, a new line was added, identifying the contribution of lessons learned to the knowledge base as a deliverable part of every future contract. Hmmm, guess what? Suddenly every project management consultant seemed to find some new time. No contribution, no final payment for the contractor. This wasn’t a big corporate decision, Moses was not required to come down the mountain with stone tablets, it was a little one-line change to a contract template that turned the ship… a trim tab.

The other expert in this session had project managers who were not contractors, they were employees. Holding back payment in this scenario could not be one of the options. In this firm, a similar impact was made. On the project manager job performance review form, a new line was added. Project managers were now to be graded in their contribution to the project management process. Surprise, surprise, within a few months, project managers seemed suddenly interested in a process that they would have been hard pressed to identify in the past… trim tab.

What I like about both of these examples is that they started surreptitiously. All too often, when organizations attempt to implement a system company-wide, it starts in one of two ways. If the system originates from the mid-levels of the organization, then it rarely comes with the authority to deploy with every department and every user and often stalls within a close-held group. If the system originates from a high-level of the organization, then all-too often it comes with too heavy handed an approach. While upper management almost always has the authority to impose a structure, if it tries to impose a change in culture without considering the human impact, it runs the risk of creating “covert saboteurs”, staff who pay lip service to the new system yet make every effort in the background to stick to the old ways.

Culture change can be a sensitive thing. If imposed too quickly or too drastically, employees may feel threatened, their familiar world turned upside down. The most impactful changes are usually those which sneak into the system and the best way to deliver those changes is through small changes in procedures. Changes that at first glance don’t seem to change anything significant.

If you’re interested in change in your own organization, start looking for those trim tab opportunities. Ask yourself what change in function or practice would result in behaviour that would contribute to the deployment of our enterprise-wide system. Then, before implementing that change, ask yourself what the likely reaction would be to implementing that procedural change. If the reaction is likely to be major, you’ve not found a trim tab, you’re trying to push the rudder itself.

Of course, sometimes there’s simply no choice but to go with the brute strength approach. For example, organizations faced with a shortening calendar before the year 2000, find themselves implementing complete overhauls or replacements of core organizational systems. Where changes might have been better implemented over time, these firms must drive quickly, pushing the system in where it is required. If this is the scenario you’re facing, then other methods can mitigate the potential negative impact. Skilled ERP implementors use focus groups and familiarization sessions in part so that nervous recipients of the new system can express their concerns and have their issues answered by people with the control to deliver answers.

No matter what your situation, keep looking for those unique and powerful opportunities to enhance the situation in your own organization through the smallest of changes, the trim tab.

When Resources have to come from nowhere

One of my favourite advertisements for project management software over the last couple of years shows a harried project manager with his head in a photocopier trying to clone himself in a desperate attempt to get more resources for his project. It’s a sentiment almost everyone in the IT community can sympathize with lately. If there is a CIO in the country ready to say “I’ve got more than enough resources,” I’ve yet to meet him.

The tradition method of increasing resource levels has always been to just hire more. Yet that option is becoming increasingly difficult for various reasons:

First, resources are often scarce. With IT project being ever more complex, programmers for varying development environments, systems analysts and others are sometimes hard to find. Recruiting and retaining key staff has become a full-time job for some managers.

Secondly, certain key skills are harder to come by than anything. One of the things that IT project managers come to know quickly is that the resource they absolutely need is the same person every other project manager in the organization needs. The particular combination of knowledge, skills, knowledge of existing systems and experience makes certain technical people unique.

With the traditional method of resolving resource conflicts cut-off, many CIOs are looking to become more effective at managing what they have. Getting the most out of your resources is one of the promises of project management software and so it is no surprise a that the Project Management Institute is seeing more new members from the computer industry than any other.

So, what can you do to get the most out of your resources? Here are a few suggestions:

Find out what people are actually doing
This is no small thing. In many organizations, the amount of time “lost” in unallocated time is startling. For these organizations, there can be tremendous improvements in efficiency just in determining what people are spending their time on. An electronic timesheet system designed for project use finds a good target here. The system should be able to restrict the permissible charge codes to only those which have been created and authorized. This prevents countless hours from the dreaded “999 – miscellaneous” code. In one organization we’ve done some work for, implementing an electronic timesheet system “found” $60,000 worth of hours in the first month alone.

A corollary to this is to ensure that people are doing what they were scheduled to do. When we implement an enterprise-wide timekeeping system, managers are almost always amazed at what people are spending their time on. In some cases, staff members start working on tasks which were never part of they original project specification but that they think will be important.

Prioritize
Getting the right people to work on the right task is the next challenge. Project Management software which can identify tasks which should be completed before others and tasks which will have a greater impact on the total project (or projects) schedule allows a department manager to keep people focused. Applying an 80/20 rule to the problem says that 20% of the tasks will likely take 80% of the time. No problem if these are the most critical tasks on the project but in example after example, we come across projects which are running late where a significant proportion of the development team are mired in program cosmetics which were never part of the original specification (cute though they may be). A very clever coach once told me “work-ability before impeccability” telling me that while impeccable work was desired, just getting it working was ultimately more important. I’ve heeded the lesson since. When we do development now, we get the function working, before we add the spice, bells and whistles.

Resource Levelling
Some project management systems do a good job of providing resource levelling analysis. This analysis tells the manager where tasks will have to be scheduled in order to get the earliest possible date with the resources available. An advanced package will include the ability to show both a time-constrained analysis and a resource-constrained analysis at the same time. The time-constrained analysis assumes that additional resources could be made available but that the project schedule is inviolate. A report of this type of analysis will show the additional resources required in order to accomplish the schedule. The resource-constrained analysis assumes that no additional resources are available and that the schedule can be extended. A report of this type of analysis will show how long the schedule must be extended in order to complete the work with the staff available.

Neither of these analyses should be taken at face value. There are many techniques for advancing a schedule with limited resources including re-sequencing the tasks, changing durations, applying overtime and so on.

What is useful here is to find periods of peak resource requirement early enough to allow the manager to make preparations or to mitigate the problem. If there is enough notice, the manager can make a remarkable impact on the availability of resources for other tasks. Options for the project manager to consider include sub-contracting work, changing priorities of tasks, putting some low-priorities on hold or not starting some low-priority projects which might have otherwise taken up time. One of the things to consider is doing some work in advance in order to take advantage of some under-allocated time even if logically some of that work wouldn’t be done yet. For example, one wouldn’t typically start writing documentation until a piece of software was substantively complete. However, it might be possible to write quite a lot of system documentation and user documentation based on in-house standards and specifications. Even if some of the work had to be edited later, you would have gotten a huge jump on an area of a project which is typically a vulnerable point for project delays.

All of these techniques won’t create new staff in the morning but they have the potential to create tremendous efficiencies in resource management. Implementing any or all of these will almost always involve culture changes in your organization and, as I’ve said before in these pages, culture changes are not the easiest thing to implement. Take it one step at a time and make sure you involve the whole staff so that people know what the potential gains are for everyone if your operation becomes more efficient.

Of course, if that doesn’t work, the photocopier option is still available. It just seems, no matter how many times I stick my head in it, the copies that come out never seem to do as much work as I do.

Thanks to Scott Adams for a good laugh

I’ve been enjoying Scott Adams Dilbert comic strips for years. They’re a treasure trove of laughs for people in the project management or timesheet software business as I am. Adam’s Dilbert website has too many old strips to choose from so here’s just one that had me chuckle today.

Sometimes it’s better to look integrated than be integrated

Integrated project management environments are the envy of almost every executive in the country. In virtually every computer publication available there is talk about corporate environments being single source. Yet another TLA (Three-letter-acronym) has crept into our lexicon; ERP. It stands for Enterprise Resource Planning and generally describes large, centralized corporate systems which include not just the traditional financial systems but also production systems including project control. Companies like SAP, Baan and PeopleSoft have been promoting single-stop providers of project control environments. The year-2000 issue has prompted many companies to replace their corporate systems wholesale and this has further fueled interest in a centralized environment.

In the project-management industry the word “Integration” has been used so much as to become an oxymoron. Adjectives of varying degrees from “Totally” to “Seamless” to my all-time favourite “Watertight” describe systems which supposedly form different aspects of a complete solution for managing projects. In our company we’ve talked about the “Integrated Solution” so much it’s embarrassing.

But is it always productive to shoot for the “total” solution? There are several factors to consider. First of all, is the solution that looks so “integrated” in the brochures in fact as integrated as it promises? There are a number of vendors who have taken systems from different development teams or even acquired companies with products which were missing from their notion of an all-round solution and glued them together. Sometimes the most integrated thing about this combination of products will be the brochures themselves. It’s important to understand exactly what is meant by integrated different systems together even systems which seem similar in interface.

The acid test for integration used to be a proof-of-concept test where files from one system are readable by another but in practice this is not nearly enough. Data can never be considered in isolation. One of the more impressive examples of pre-sales testing I’ve seen by a firm recently has us doing our homework at the office. This firm has spent the last 90 days or so not looking at product features but rather generating data and scripts for testing. When they get to completing their tests between the 3 products they’re looking at later this month they will be looking at the data in as close to real terms as possible and they will be looking at the flow of data through the entire project control process. Seem like a lot of work? It is but the hidden bonus here is that when the system is implemented, there is already a very good system description of the control environment.

The second factor to deal with is understanding for yourself exactly what you require in terms of integration. We were asked recently for example if our TimeControl timesheet system would update the project scheduling system in real-time. It was this executive’s notion of the ultimate in integrated systems. As people completed tasks in the middle of the day, the project budget vs. actual would instantly adjust showing the advance of the project details. Sounds great but isn’t implementable. Aside from the problem of doing validation of the actual time and never knowing if all of the data has been collected (Ever had to find missing timesheets on a Monday morning?), the data would never be stable enough to be used for comparison against a budget. The issue here is that the data had never been considered as part of a process. For each organization, the requirements must be considered.

Finally, the benefits of being integrated inevitably trade-off against a higher degree of overhead for the total system. It doesn’t take long to see this. Imagine two systems, say a timesheet system integrating with a scheduling system. We’ve decided to tie these two systems together so that we can see budgeted costs vs actual costs. Sounds great but by integrating these two systems we’ve got to take on a couple of additional tasks. First, tasks in the scheduling system will have to be made available to the timekeeping system. Regardless of how “seamless” this process is, some degree of communication or coordination must be made between the keeper of the timekeeping system and the keeper of the scheduling system. Coding of the two systems must be coordinated. A process must be established for the movement of actual labour hours from the timesheet system to the scheduling system. A system of checks and balances must be established to ensure there is no data missing in the process. Another system of corrections must be established for inconsistencies between the two systems. Even in the most “integrated” environment, there is no escaping this establishment of proper process. Sound intimidating? It’s not really but it’s not trivial either. One of the most significant causes of failed integrated environment implementations is a misunderstanding of management of the process. Is it worth it?

So what are the options? Well, it’s worth considering at least having different categories of data to work separately. Look at the individual applications that you’re considering as part of your project control system. What benefits are available from each implementable aspect of the system when it is not integrated into the whole. If you can’t find any, you should be reconsidering why you’re implementing that feature in the first place. Examine how you could implement each aspect of the system distinctly and see if the benefit outweighs the payoff. If you are looking at products from a single vendor ask them to outline the benefits/costs of implementing systems separately. If you’re considering products from multiple vendors ask them each how they would make you more productive when these products are working in tandem and how they’d make you more productive if the products were implemented stand-alone.

Finally, don’t start anything without at least a rough implementation plan. Make sure all the players know when the system should be firing up and when the first benefits can be expected from different aspects of the system. You can always adjust a plan that wasn’t ideal but starting without a plan will ultimately cost you more than the purchases of the systems you’re considering.

Oh, what a year it’s been!

We’ll look back on 2009 philosophically one day but there are many who are happy to see it come to an end. When we started 2009 we had challenges in various sectors of the project management community. But there were signs of things improving. The US had just elected a new president; a man full of hope and promise. The world’s auto industry was challenged but help would be on the way with a new administration.

In the project management software world Microsoft had grown the project management software business yet again and its main competitor had recently been bought by its arch rival Oracle. It promised to be a very interesting year.

Who would have predicted the depths of the financial industry crises or the incredible amounts of bail-out money that would be allocated to the private sector?

Project Managers all over the world have had to fight to keep their jobs this year, some of them unsuccessfully. With less money comes fewer projects and with fewer projects we need fewer project managers. Not every industry has been affected the same way. Some project management consulting firms have had their best year ever. If you do work with the public sector there was suddenly a big shift towards spending money in a hurry with all that bail out money needing good governance. If you worked in the health sector, the H1N1 scare had all kinds of industries from vaccine distribution to hand sanitizer manufacturing scrambling to expand at breakneck speed.

The aquisition of Primavera by Oracle seemed to have little effect in the short term but my experience reminds me that effects of such mergers are usually slow in coming.

2009 may have been hard for some in the industry but if you struggled this past year, take heart. There is light at the end of the tunnel.

2010 has some interesting changes for those in the project management industry:

Here at HMS we’re going to finally release our TimeControl 6 product. There’ll be lots to say about this as we get 2010 underway but we’re very excited about this long standing project finally coming to market.

Next, Microsoft will release Project and Project Server 2010 “sometime in the spring” of 2010. A major new release of project management software always seems to bring out changes.

The bailout money from various governments around the world that made such headlines in 2009 is only now starting to hit the streets and as it does a variety of industries will scramble to execute on projects that money and derivatives of that money make possible. Even if you’re not on a direct bailout path, the recovery of a lot of the financial sector has made equity numbers improve and as a result, commercial credit is making a slow comeback. As it does, more and more projects will become possible.

I predict one of the most interesting years for enterprise project management as a drive for efficiency takes center stage ahead of a drive for government compliance.

Happy New Year everyone. Let’s make this a great one.

Archive: January 21, 2010

Changing a Culture happens one tiny procedure at a time

When Resources have to come from nowhere

Thanks to Scott Adams for a good laugh

Sometimes it’s better to look integrated than be integrated

Oh, what a year it’s been!