Category: Computing Canada

Home Articles Computing Canada ()

Article: Getting over the first hurdle in EPM

hurdle

The lesson was brought home to me in an unusual setting. I was speaking to a chemical expert who specializes in commercial swimming pool chemicals. He was explaining how the chlorine in the kills the bacteria which carry the bad bacteria. Until you reach the critical mass of chlorine, he explained, zero chlorides have been used and no bacteria destroyed. Once you hit the critical mass, all the targeted bacteria in the pool die and then you have to maintain the minimal critical level of chlorine to keep the pool safe.

What does this have to do with enterprise project management systems deployments you ask? Everything. Take a recent case in point that we’re working on right now. This is a CRM system deployment. The client has (not unusually) completely underestimated the total effort required to deploy the system. They’ve elected to put in a minimal budget with the thinking that their own personnel will be able to carry the project forward at a leisurely pace. The budget had very little room for experienced and expert assistance and was mostly focused on functionality training. Internal technical personnel were also budgeted for the smallest possible amount of time perhaps thinking that the internal personnel would be as efficient as a consultant who had done many of these implementations.

I’m sure you can see where this going. The budget for both external and internal technical expertise was quickly expended and, while the CRM system is installed and has some elements of the functionality working, there are large areas of the product which cannot yet be used because either they aren’t at all functional or they have not been configured with the necessary templates. Underlying architecture is also an issue. In one case the web server required both an upgrade and additional configuration and in another an incomplete installation of Microsoft Exchange had to be tackled. The end result is that the system does not yet have sufficient forward momentum to ensure it’s viability as a corporate system. What will happen here is that either the company will let the system limp along until something better comes along, or the system is abandoned or until it applies a bunch more resources and money to the project (perhaps even more than would have been required originally since they’ll be trying to rescue a project that’s already underway).

Sound familiar? I hope not. But this is exactly the scenario we often see in the enterprise project management space. The amount of effort required to validate the infrastructure, install the software and (most of all) configure the final system is underestimated about 90% of the time. A compounding issue is that the level of expertise and experience required is also almost always underestimated. The result is that systems do get installed but have elements that are not working and too little time to configure the system to deliver the results that were expected when the deployment was authorized.

There’s not a panacea for such deployments. Educating management, if possible, can reduce the heartache. If you are involved in an enterprise project management systems deployment, then determining the minimal working system may be a critical step in your planning. Aside from defining the complete deployment requirement which may be daunting to management, determine also, what effort would be required for a ‘viable’ deployment. One which, even if not all the functionality was deployed, would realize enough business benefit to be worthwhile. If you do, then the system will still be around to expand on later. If not, then you might end up with one more system to be rescued or replaced and all your efforts wasted.

Article: EPM means different things to different people

Tower of Babel

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. 

 

Article: Centralized or de-Centralized Project management

7252413

As the notion of enterprise project management becomes more prevalent in the industry, we’re starting to see epm approaches divide into one of a small number of camps.  As I’ve said a number of times in this column, there are many perspectives of project management in an organization and lots of different approaches to how to empower each of those perspectives.  One of the major choices that a new project management office has to deal with is who will be responsible for the data itself.

 It’s a basic tenet of systems analysis that for each piece of input data there can be only one person responsible.  If there are multiple people responsible for a single entry of data, managing the quality of that data becomes very difficult.  So, when we see Project Management Offices get set-up for the first time, one of the key challenges is to decide if the role of the PMO personnel is to collect, analyze and report on project data or if there role should be more as a coordinator, bringing the data of many individual project managers and even individual team members into a cohesive collection of data.

In the first scenario, the PMO will look for a high-end centralized project system.  Project managers will put the bulk of the project management data in directly or with the assistance of schedulers.  The individual team members will see reports out of the centralized system and there input to that system will be either as a part of meetings or, perhaps through their timesheet system.  This type of system will typically have advanced functionality for critical path scheduling, resource leveling, skill scheduling, multi-project analysis, risk analysis such as Monte Carlo analysis and extensive reporting capabilities.  Sounds great of course, but this type of product will work best in the hands of skilled project scheduling workers.  We see this type of tool in environments where there are a small number of projects which are very large and complex.

In the second scenario, the role of the Project Management Office is designed as a clearinghouse for work which is being managed in a much more decentralized manner.  In this case, team leaders or project managers of much smaller elements of projects work on their own project data.  The team members are given direct access to the system and interact with it to find out what they are working on and to update the schedule with their own progress.  This type of system is oriented more around collaborative functionality.  There will be tools for individuals to customize their own views, to see system announcements and online discussions, to get alerts for project changes, to add collateral data to the project such as documentation, issues progress notes and more.  There is usually less emphasis on reporting in this type of system because the system itself is typically available to everyone.  Instead, you’ll find more emphasis on personalized online views.  We see this type of approach in an environment where there are numerous projects which share resources.  A matrix organization would find this type of tool a good fit.

Again, this sounds great.  This type of product will work best in an organization where the individual project teams are empowered to function more independently but still interact with the rest of the organization for elements such as shared resources or portfolio prioritization. 

Which is the right approach?  It’s a trick question of course.  For each organization, you’ve got to look at what the key business drivers are.  There’s a definite tradeoff.  The centralized system will bring a lot of data together where it can be managed in the hands of highly trained individuals.  The reports and analysis will likely be first class.   The problem may come in the ownership of the results by the team members who are affected.  In the decentralized system, individuals are likely more empowered and the project management is done closer to the actual work.  The challenge becomes getting sufficient conformity and compliance to have the consolidated data make sense.

One key to staying effective is to make sure that your project management office is organized to correlate with the organization’s approach.  A common problem is to find a PMO who wants to be centralized in an environment which is de-centralized.

 

Article: It’s better to look integrated than be integrated

7276253

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”.

Article: Bypassing the Dotted Line

pmo-dotted-line1

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.

Articles: Scorecard source data needs standards

scorecard

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.