2010 is an Olympic year in Canada.  Every time the Olympics come around, I must admit, I get emotional about those athletes who have given so much of their lives to participate in the greatest sports spectacle of our generation. I have a daughter who swam competitively and, as many parents do, I was struck with awe by the amount of effort she dedicated year after year to improving herself in her chosen sport. I’ve had the privilege of being at two Olympic Games. At my first, in Montreal in 1976, I worked at the games helping to raise the flags at different medal ceremonies. It meant hanging out a lot with people who had just won medals and had a profound effect on me. In 2000, I was able to take my wife and daughter to Sydney where we enjoyed the games as spectators. The perspective was very different. Perhaps having a teenager who goes to practice 7 times a week (2 mornings, 5 evenings) for 2 hours or more at a time, gave me a different look at the games but it struck me that the games aren’t so much about who wins. It’s true we obsess over medals but of the 10,000 athletes or so who are participating this year in Athens, only 500 or so will win medals. The other 9,500 have devoted years, in some cases more than a decade of their lives, to intense personal development and will have little or no hope of winning a medal.

When I bring this back to the project management industry and the organizations that I work with who are deploying enterprise project management systems and processes, the parallels are evident. Deploying epm isn’t trivial. Being successful in an epm deployment has a lot to do with treating the project seriously and being ready to do what it takes.

We have no trouble counseling a teen that to succeed in sport will take dedication and hard work but all too often we diminish the work required to make an epm deployment work.

Year after year we talk to mid and large organizations who wish to implement an enterprise project management system. It’s not just me, but many, many sources of information who outline what will be required to make epm work. Yet, somehow, time and again, someone in management characterizes epm as a technology project or as a simple software installation. The impact that changing how project management works might change the character of the entire organization is rarely identified. Yet many organizations in the past 20 years have become project driven. Project management has become a mainstay of management thinking and project management is definitely a horizontal industry.

Projects affect everything about an organization; where the money is spent, how effective the organization is at delivering new products, how fast revenue can be generated, how resources are allocated and much, much more. The idea that the installation of some new software will instantly transform this broad-reaching process from a silo-oriented single-user process into one where diverse employees and departments collaborate is optimistic at best and dangerous at worst.

We should take a page from those Olympic athletes who have planned and strategized and (let’s not forget) worked for a long period of time to achieve their goals. The question, you’ve got to ask is, ‘Are you ready to do what it takes?’

Tower of Babel

One of the biggest challenges we have when we arrive to implement enterprise project management (epm) is the wide range of definitions of what is meant.  The problem is compounded when we fold systems into the conversation.

Depending on your perspective, enterprise project management might mean very different things.  If you are the CFO, then epm could mean tracking project costs in a consistent manner across all projects or might mean just being able to categorize costs by project.  In this case, focus rests on the centralized accounting systems or a new ERP system which becomes by default the epm system.  Appalled?  Don’t be.  For organizations which have not been able to do this before, having the actual costs per project is revolutionary. 

Other aspects of project management that people think about include resource capacity planning, inter-project reporting, portfolio management, earned value analysis, integrated annual budgeting, matrix reporting, schedule tracking, resource contracting and team collaboration or team communications. 

For some organizations, epm means just being able to track the detailed labour actuals on a project-by-project basis including details down to the task level.  In this case, a corporate timesheet becomes the central epm system. 

‘Where is the project plan?’ you ask in shock?  In this case it would be managed at the most summary level.   

For people like me who are somewhat project scheduling purists, this seems at first glance to be just awful.  When I think Enterprise Project Management, I imagine integrated corporate project schedules and centralized resource pools and cross-project resource capacity planning.  But this just betrays my own bias in the conversation.  For each organization wishing to improve their ability to deliver projects, the leverage will be found somewhere different.  I have been asked virtually hundreds of times for a timesheet system not to ‘integrate’ into the project management system but to ‘be’ the project management system.  When I bring up planning, it’s not unusual to hear the following from a senior executive:

“Yes, formal integrated scheduling would be fine but, you know, before you showed up, projects were underway.  They’re underway right now, as we’re speaking.  This is happening despite the absence of a centralized planning system.  We have a good handle on the planning, what we can’t tell you is where our people are.  If we could just know from week to week what effort we’re actually spending on our projects our control would be so far ahead of where we are now it’s unimaginable.” 

The first time I heard that was years ago and it stopped me in my tracks.  My purist view wasn’t so important anymore.  What counted is getting the right metric into the right hands. 

So, when you’re looking at creating an epm system, don’t fret that you’re doing it wrong or that the last project management software vendor showed you aspects of project management that you’re now sure everyone is doing.  Look at the different aspects of what you can control and start with that area that will deliver the biggest return on your investment of time and effort. 

I’ve been looking through old articles from about fifteen years ago to find the exact example but my memory will have to suffice.  Years ago there was an advertisement for one of the large systemhouses (we’d call them integrators today) whose slogan was “It’s better to look integrated than be integrated.”  We laughed about it at the time but, amazingly to me, there is a certain amount of logic in the silly phrase.

Recently we entertained a software integrator who was looking to provide a “complete project management solution” to his client.  He was looking for “a seamlessly integrated solution”; something many of us in the industry have heard the request for in the past.  Once we had sat down I had to ask what exactly he meant by integrated and whether his client in fact wanted that.

The answer wasn’t as quick in coming as my question has been and it serves to illustrate that what we’re asked for by clients and staff alike can often be interpreted very differently.

In this case we were looking at several timesheet solutions which would integrate with Microsoft’s Project Server.  In one case, the timesheet interface was embedded into the Microsoft Project web interface and had its data directly linked into Project’s.  However, this selection had very little ability to link to a finance system.  In the second case, the interface was again embedded into the Project Web interface and the data linked directly to Project Server but the interface to the Finance system was at arm’s length through a transaction file.  In the final product, the interface was completely separate from Project’s but the data highly integrated to both Project Server and the Finance system using SQL triggers

Once we had categorized the selections this way, our first question to the consultant was, ‘What did the client want?’  The answer would require a couple of days of communication to get from the client. 

When we think of integrating the functionality of multiple products together to form a single technical solution, it’s worthwhile to divide up the analysis into a couple of areas. 

First off is almost always the data.  The products can look like they’re part of the same solution but if the data can’t interrelate in some way; you have to think seriously about what you’re delivering.  Creating a flow diagram, first of the data, then of the workflow is often an important step here.

Next, think about the functionality itself.  Does this blend of two products overlap functionality or actually deliver something that can’t be done by one product or the other.  In our situation with timesheets, this issue is common.  There are so many different types of timesheet systems; each with its own perspective, that you have to be very clear about what business problem the client will solve using a particular timesheet selection.  This challenge is compounded by the fact that most timesheet interfaces look very similar.

Finally, look at the interface.  If the user will have to move from one type of interface to a very different type of interface with each function, you have to consider the mindset shift required to go from one thing to another.  Sometimes, just looking very different can it hard for a user to consider that the underlying data is, in fact, related.

Take a bit of time with each perspective.  First impressions are sometimes off-base.  For example, in our situation, the consultant was absolutely certain that the ability of the timesheet to integrate the data at a very intimate level in real time was a must.  In fact, when the client was told that we had the ability to move data into their ERP system in real time, they were very upset.  The Finance Department told us that it had taken such a significant effort to stabilize the ERP system that they had no intention of “pushing” data into it from an outside source regardless of how safe it appeared.  A transaction file that they could import on a scheduled basis made them much more comfortable.  They said they’d rather “look integrated, than be integrated”.

…

It’s a subject that comes up every time I talk during training courses about the role of project managers within organizations.  The project managers are usually pumped up full of self importance having just learned how to do something clever that they believe will revolutionize the way projects are handled in their company.

I start by drawing a simple Organigram of a typical organization, CEO at the top, CFO, COO, CIO at the next level, other boxes without labels below that.  Where, I ask does the project manager live in this Organigram?  It makes you take pause because the answer isn’t obvious.  Often people will tell me where they wish project managers belong (usually somewhere very far up the food chain of course) but the real answer is often less satisfying.  In most organizations, project managers live as a dotted line to the left or right below a CxO of some kind with no direct authority at all.

For newly frocked project managers brimming full of new ideas and techniques, this is like throwing a bucket of water on a good campfire.  Yet, this is a phenomena that every project manager must come to terms with.  You may be given tremendous responsibility and even accountability but no real authority.  How, then can a project manager with all the techniques and tools we discuss in these columns month after month bring those tools to bear on the organization to effect change?  Well, aside from begging, groveling, cajoling, issuing empty threats and bribes (all techniques I’ve recommended here at different times over the years), there is one tool that has phenomenal power and that tools is wholly in the control of good project managers.

Science tells us through a principle called the Hawthorne effect that the very act of measuring something changes the thing being measured.  The Hawthorne effect (please don’t ask me where the name comes from) was demonstrated in a water study done in Tucson, Arizona.  A couple of water researchers named Woodward and Hirshon were studying how water was being used in Tucson households.  In the study, it became apparent that as soon as people knew that water meters were measuring the water used in different ways throughout the house, their use of that water decreased remarkably.

Of course, the effect was only apparent when people knew they were being monitored.  If the measuring is secret, there is no effect at all.

This effect translates very nicely to the project management paradigm where most project management tools are all about measurement and then display of the data.  In fact, the manner in which data is displayed has a profound effect on both the people doing the work and those managing it. 

Imagine a project team can see consistent data that shows the project is understaffed due to a low priority ranking on a portfolio grid.  The morale of the team might be terrible, thereby contributing to poorer performance. 

On the other hand, imagine showing a project team a report which shows the pace of work and the trend over time in which it is obvious that the team is now closing in on a particular target that it once thought it might not attain.  It would be easy to imagine this team redoubling its efforts to make that milestone!

The power of generating targeted project displays which generate particular effects can’t be underestimated.  Any senior manager who has had a highly skilled project management system user or report generating expert knows how important it is to keep that expertise close at hand.

Making this type of tool a powerful weapon in your project management arsenal means getting data to be centrally stored so it becomes accessible and knowing the project management tool that manage the data so you can display it to your best advantage. 

Project managers living at the end of a dotted line can take comfort from knowing the power of project displays and who gets to see them can radically affect the behavior of an entire organization.

There are numerous scorecard solutoins on the market today including PerformancePoint from the ubiquitous Microsoft.

If you take a look at any of these systems, the sheer prettiness of the display is usually breathtaking.  PerformancePoint for example provides a central point to create formulas and displays for Key Performance Indicators (KPIs) which are then made into a variety of context-sensitive scorecards or visible displays.  A demonstration of the system shows data from a variety of sources including financial, sales and even geographic were woven into a single display. 

The cream topping of such a demo is perfectly positioned as it often integrates data from project management tools like Microsoft Project Server woven right into the Business Scorecard display.  The whole structure sits within Microsoft’s Sharepoint Portal Server technology which, if you haven’t seen, is probably worth a look.

Now, Microsoft gets plenty of plugs and certainly doesn’t need mine but this display can be impressive.  I’ve been doing a bit of looking at scorecard systems since I wrote about it in this column over a year ago.  This new product by Microsoft is certainly not the first scorecard product on the market.  It’s been preceded by many others but I find it interesting that the movement has picked up enough momentum that Microsoft felt compelled to enter the industry with its own offering.

After a recent demonstration by Microsoft, I was approached by several attendees who discussed the relevance of using Scorecarding with Enterprise Project Management and of course, I reiterated my enthusiasm from a couple of years ago.  One comment in particular however, brought me up short.

If the underlying data has questionable quality, said one of my colleagues, wouldn’t that make the entire system suspect?

It has gotten me to thinking and, the more I think about it, the more it disturbs me.  The answer is yes of course, but I realize that in the systems we design and deploy that there are huge assumptions in the enterprise project systems that get deployed. 

We depend in great part on the natural human filtering that goes on when data is examined and entered.  In systems which have an extensive legacy culture such as core financial systems, we accept the basis of how data is entered because it is common to all organizations. 

It is when we apply the same notion to other enterprise systems that we often see how challenging it is to establish stability in this type of data.  CRM, Enterprise Project Management, HR type systems turn out to all require a remarkable amount of effort to make their data as trustworthy as core financials. 

It’s not the technology, of course, it’s the standard for using that technology which must be adapted with sufficient uniformity to make sense.  In my own firm, we’re currently struggling with CRM terms for what makes a lead vs. a contact, vs. an opportunity… well, you get the idea.

When we create an executive display system to roll all that data up to easy-to-read one page displays on which core business decisions are made, we’ve got to take pause.

I’m sure executive dashboards of scorecard type information will be hot sellers but before we deliver a system that eliminates the need for human filtering of data, we’ve got to make sure that the underlying source data for those displays delivers what we need.  Not doing our homework with this kind of system could pay back dividends that won’t be too welcome.