Category: Articles

Home Articles ()

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.

Article: Big Bang or Phased Approach

Big BangDeploying an enterprise pm system is the current hot thing – What’s more effective? Creating the perfect process then deploying across the entire enterprise in a Big Bang or phasing-in a less mature process bit-by-bit?

I find myself on the meter a lot recently.  It’s not something I’ve done for quite some time but the trend of businesses of all sizes to deploy enterprise project management systems has our staff asking me more and more to get involved in the early stages of these implementations.  In particular I often now seem to find myself working with organizations on the strategic plan for deploying an enterprise project system.

If you’re just getting started to working on an enterprise-wide pm initiative, you have lots of company.  One of the first things you’re going to have to be clear on is that most significant challenge in moving forward in the early stages is not the selection of the right tool or the adoption of the ideal pm process; it’s the understanding that what you are involved in is a significant change-management project.  While I’ve talked about this before in this column, it’s worth mentioning again I think that the culture impact of an organizational change towards management by project in a centralized fashion is no small thing.

That being said, the way most of these projects go in the early stages seems to start with the striking of a project team and asking that team to then make a plan.  The first debate is almost always when I seem to arrive and that’s on basic deployment strategies. 

People who have been around the pm game for awhile will most often want to take this golden opportunity to step back and review or even create a proper project management process.  “Tools are a secondary conversation,” they’ll say.  “Something to be chosen only after defining the process on which those tools will be applied.”

It’s hard to argue.  I’ve been in the pm software business now for almost 20 years and I’d have to say that adopting a productive pm process and then applying the right tool seems much more sensible than choosing a tool without a clear understanding of how it will be applied.

The proponents of this plan would have a committee work on developing the right process in a sort of laboratory where ideas could be worked on without affecting the projects already in production.  Once the process was finalized, the right tool would then be easier to select and the deployment would now be done in a rapid fashion, moving personnel as quickly as possible, perhaps even simultaneously into the new process and new tool as defined.

Well, as good as that sounds, there are a few inherent problems with it.  I’ve been in several organizations now watching people attempt to do this very thing and here are a few of the challenges they’re facing.

First of all, life does not occur in a laboratory.  The project personnel who are working in the front line aren’t likely to adopt something that comes out of a lab without getting buy-in themselves.  In fact, the whole idea of an enterprise pm systems scares the heck out of some of those people.

Recently while talking to a project manager in the telecom industry I asked what he thought of the changes that were reported to be coming.  “I can’t see that stuff making any difference,” he said.  “I use my own system of managing a project; I’ve had great results and I’m not likely to change the way that I manage so some suits in the head office can get reports minute by minute on what I’m doing.”

While I was at another firm, this one in the aerospace industry, the person in charge of the enterprise pm system deployment tried to explain her difficulties in getting a corporate-wide WBS adopted.  A few short questions later and it had become apparent that the scope of people involved in her quest spanned 4 divisions of the firm.  She had no one supporting the project from further up than the manager of her own division.  Personnel in the other 3 divisions, in the absence of management directives from their own managers, were being polite in listening to her but had no intentions of ever adopting her proposals.  In the meantime, the implementation of a pm tool where data could be centralized was paralyzed with the inability of the organization to get over this coding question.

One of the other phenomena I’ve noticed in these kinds of deployments is that no matter how much time the central committee spends trying to write the ideal pm process, the plan lasts until the first day of deployment.  Inevitably, as soon as the process is out in the field and seeing the use of actual personnel on actual projects, the process needs to be adjusted; sometimes completely reworked.

So, despite all the evidence from my purist sentiments that cries out to get the process right first before deploying in a big way, I’ve got to vote with the phased-in approach.

A Phased-In approach starts the actual deployment much quicker with a smaller group of people or a subset of the total number of projects.  In this scenario, the time spent on the global process is minimal.  The idea is to get a system going that looks like it will be able to handle the needs of the whole organization and start producing some benefits with it quickly.

Because the process is poorly defined in such a deployment, you’ll have some teething pains that will require more effort in the early days.  You will have to budget more time, more assistance and maybe even more money for the early adopters of the system.  But these amounts will still be a tiny fraction of the cost of adopting the entire system in a Big Bang approach.  You’ll need to pick strong early adopters because you’ll be developing the process on the fly as you work the system through the first pilot projects. 

The great news about this plan is that management can start seeing results early.  The presence of more assistance in the early days from the deployment team almost makes this a certainty and getting more management support makes a world of difference as you work through the organization deploying to more and more people.

There are decided advantages and disadvantages to each approach.  I think it’s probably true that the Big Bang approach is more likely to get closer to the initial vision of the enterprise pm system.  The phased approach has a good chance of reaching some level of organization satisfaction and thus complacency before the ultimate vision is reached.  Yet I think it’s also true that the Big Bang approach has a much more likely chance of going absolutely nowhere; stalling somewhere in the definition phase, without getting people to agree on how to move forward even to the first step.  The phased-in approach starts almost immediately and thus the company has a much higher chance of realizing some returns on the investment of time and energy that any such project involves.

Either way, remember, you’re dealing with change and change invariably causes upset even when it’s ultimately a change for the good.  Plan for that and you’ve got a good chance at making your enterprise pm system a success.

Article: Unstoppable force vs. Unmoveable object

72762531

With both Microsoft and SAP taking a newfound interest in enterprise project management, an all out battle between these software behemoths seems inevitable.

There’s a battle brewing in the project management software arena and we’re just seeing the beginning of it.  Not long ago I spoke in these pages about the movement of Microsoft with Project 2002 into the enterprise project management space.  This had previously been the domain of only a select few project management software vendors who had quaintly become known as “high-end vendors”.  You know who I’m talking about; the Welcom’s, Primavera’s and Artemis’s of the world.  Well, less you were worried that Microsoft will be left an open field, there are other software giants also interested in the booming enterprise project management software market.

SAP, who’s impact on the ERP market in a relatively short time has been remarkable, has also taken aim at winning the hearts and minds of project managers everywhere.

Although the target seems the same, the approaches of these firms are quite different.

First of all, the notion of enterprise project management software is hardly new.  The very first project systems created on mainframes were directly targeted at enterprise work.  It’s true that the projects that would warrant project software in the early 70’s had to be mega projects in order to afford the software, hardware, implementation consulting and training costs required to make one of these systems work yet the analytical results went directly to management.

The increasing affordability of computing power and, in particular, the acceptance of Windows brought project management from a centrally controlled project management office to virtually anyone interested.  Even where no central project management existed, organizations could now enjoy some of the benefits of project management software because it was so easily accessible to end users. 

In the last few years, however, increasing interest in returning project data and analysis from individuals into the corporate pool has resulted in a newfound interest in centrally maintained project management.  Thus the interest in project management software that could bring these project individuals back together.

Microsoft’s latest release is directly targeted at this desire.  It’s only natural of course.  Microsoft has been amazingly successful at capturing the desktop market for project management software.  The ease-of-use in Project has made even scheduling neophytes able to develop professional looking schedules with a minimum of training.  Microsoft has been under increasing pressure for the last several years to make Project better able to deal with issues like multi-project, central resource pools, enterprise reporting and portfolio analysis.  The now almost universal use of the Internet has pushed for more collaborative functionality; all of this designed to bring project managers together. 

SAP however, has been under pressure also.  Their P/S module was designed to provide everything management would desired in project management analysis.  Fine – if you were in management.  The P/S system however, did not start out  with the end-user ease-of-use which Microsoft had so enjoyed.  The advantage of P/S, users were told, was its direct integration into all other aspects of the ERP system.  A project in P/S would typically have a tiny number of tasks – more like cost centers or cost accounts than the tasks one would think of in an end-user’s schedule.  SAP’s deployment of the system was greated with predictable results.  Financial management people seemed to like what they saw.  The system did have the high-end reports they desired.  Project schedulers and PMO’s were less happy.  Many fought to keep their existing scheduling systems.

Like Microsoft, SAP has made advances.  In this case instead of coming up from the desktop end-users towards the enterprise, SAP’s latest P/S module targets more toward the end-user.  Speaking to representatives from both firms can be fascinating.  They could share many of the same PowerPoint slides.  Both groups are directly targeting the enterprise project market and each has the advantages and disadvantages of their legacy systems.

SAP carries the stigma of being management’s system and not the system of the end-user; of the employee.  SAP must convince the end-user project managers that their tool can handle the capacity in an easy-to-user manner and they start from a reputation (whether fair or not) of being user-hostile.

Microsoft carries of stigma of not having been a serious project management tool.  Professional project managers have carried a long-standing opinion of Microsoft Project as a tool for inexperienced or unskilled project planners.  Microsoft must overcome those considerations and convince senior project personnel that they have the capabilities to handle enterprise-level use.  Microsoft must also convince management that Project is now of enterprise-level quality and can be integrated into core financial and production systems.  All of that being said, Microsoft carries the huge advantage of market penetration.  They can honestly say that they have sold more project management software than any other firm ever.  Microsoft clearly controls the desktop market.  It has become a universal axiom that virtually every major firm owns Project.  Microsoft has already won the project management market in numbers, now it will attempt to expand the influence of Project further into its clients.

Less you were worrying about all the other software vendors I’ve not named.  The initiatives of these two firms does not imply that other pm software publishers are out of business.  In fact, many will enjoy the likely spin off effects of huge interest being focused on the project management software industry.  It does mean, however, that you’re likely to see many vendors taking a more focused or niche approach to future development.  The contest of controlling the mainstream or generic project management software market has very little room for more players.

Who will win?  The jury has been barely convened and is certainly not out.  Each of these software giants have allocated tremendous resources at making this category of software key to their expansions. However, with the vast majority of end-users already using its tool, Microsoft has what must be the lesser challenge of expanding existing use rather than SAP’s challenge of expanding Financials into a new category.  

Still, just the efforts being expended in this contest is bound to have good fallout for project managers as more and more resources will focus on bringing project management to the enterprise level.

Article: Project Management Tool Divergence

7439282

Should you implement an integrated project management system across the enterprise or go with the best of breed?  Does this mean the enterprise pm model all over?

It’s not a new topic.  The idea of integrated enterprise-wide systems has persevered since long before the term ERP was coined.  Management must have some genetic memory of times when companies were all small enough that the patriarch who would manage them would know everything about everything going on in their shop. 

Business has moved on from that comfort level and now, even in mid-sized firms, project activity tends to move so quickly that it is difficult for anyone to keep up with developments across a myriad number of projects.

The desire for an enterprise-wide project management is almost universal now.  Management perceives that having the data for every project in a single database managed in one way would provide almost real-time knowledge. 

The big ERP vendors noticed this of course.  There seemed to be nothing more compelling to senior management types than the idea that all data in the organization would be linked from one spot.  From a project that seemed delayed, a manager would be able to see a range of perspectives, showing the impact on production, on inventory, on profits, on hiring, on resource availability and on the capacity to take on more work.  Marketing would be able to determine at a glance the delivery dates for existing clients and the capacity to do work for prospective clients.

Not just the ERP vendors but just about every project management vendor has a demonstration talking about this subject and the demo data is persuasive.

Well, if this is the case, why hasn’t virtually everyone switched to some centralized ERP structure?  What props sales of products like Microsoft Project?  Why do third-party software vendors who offer only one or a few aspects of this total solution continue to thrive? 

The answer is simple but disturbing.  First of all, it has become glaringly obvious to those who have selected corporate-wide ERP-type solutions that it is very difficult to be everything to everybody.  Getting compliance up and down an organization is tougher than just instructing people to comply.  Although management is often sold on the corporate-wide system concept, the middle-managers who are actually generating the work and the data that drive the company can often show that they can be productive only when they can use tools that are suited to the particular purpose. 

Project management has many facets and one type of tool isn’t often suited to take care of all of them. 

Imagine an organization where some project management occurs at the strategic level, looking forward in global terms to the kinds of projects the company should consider working on.  In this same company,  the IT department does its own project management, supporting resource-centric management of huge numbers of projects.  Yet another group in the same company is doing shutdown management of the plant – creating a 5-6 day project where the opportunity cost of the shutdown can exceed $100,000 per hour of lost production.  Nothing counts here but the schedule – how quickly can the plant be up and running.

Could one product support all these projects into one database?  Maybe – but should it?  The data is so different, that merging it together even at a summary level makes almost no sense.  This holds true not just for a single company with diverse scheduling needs but for all kinds of firms in different industries.

No surprise then that even the largest ERP vendors are trying hard to verticalize their markets.  No longer the omnibus project solution, partners like SAP and Oracle at the high-end and Microsoft at the low-end are finding a new, hot interest in partnering with smaller players.  Software publishers of everything from document management to timesheets are linking up with much bigger partners to provide a more rounded project management solution.  This is being fueled in part by a newfound interest in the large enterprise software vendors in the project management marketplace.  Microsoft’s latest entry, Project 2002 Server coupled with Project Professional has moved it up a level into the enterprise pm space from its huge desktop presence.  SAP’s latest version of PS, has it moving off of a strictly cost-oriented project perspective down into more of a project scheduling perspective. 

This has many players moving into more and more niche markets.  Market software vendors who have been around for years find themselves working back into vertical markets even when they have been trying to diversify.  They’re back in aerospace, or back in construction, or back in engineering – selling tools and services in areas they know best and linking those tools to other aspects of a total solution.

It brings us back to an age-old conversation – should you choose best-of-breed software or an integrated solution? 

The attraction to an integrated solution seems obvious at first glance.  There is one vendor, all data is tied together in one convenient location and can be maintained and analyzed at one time.

As we’ve said in this column before however, getting that data out of the system in real terms isn’t always so easy.  There can be many barriers to completing the deployment of an integrated project solution.  The easy ones are technical, getting the database and network to cooperate.  The tough ones are often the cultural barriers to having all data in one place managed in one way.  Not everyone will share accurate data when it’s to be managed centrally and the resulting structure is almost certain to be less effective than linking multiple systems.

It is these cultural corporate barriers that foster a best-of-breed solution.  Department or division level managers are willing to cooperate if they buy-in to the tools selected.  Tools chosen by people close to the actual work are almost always better suited to their purpose.  Determining how the data from these tools will integrate to the corporate systems could be more productive than spending time trying to convince these managers and their staff to adopt centralized software which is not perfectly tuned to their needs.

Article: Resource Capacity Planning

resourcehistogram3

It’s what everyone wants but almost no one gets: Enterprise-wide resource capacity planning.  Just what makes getting this accomplished so difficult?

I’m sure I hear it at least once a week (during a trade show, twice an hour), what organizations are asking of their project management system boils down to enterprise-wide resource capacity planning.  Now I know that everyone has a little of the “grass is greener on the other side” syndrome where you think that your organization must be the only one in Christendom who hasn’t figured this out yet but the good news for you is that you’re not alone, very few organizations really have a handle on this aspect of management.  The bad news?  You’re not alone.  Many organizations are faced with a lack of power in this area of management.  I mean if you knew that some area of the world had project environments where this was always well handled, we could send people there to see how.  They could document the way it was accomplished and we could bring the lesson back to where you live to make sure it was implemented immediately.

Unfortunately, the shear number of organizations who are asking for this solution makes it clear that most organizations have not yet resolved this issue. 

Now, hold on.  If you’re one of those firms who really have figured this out, don’t be scrambling to your email to let me know that, yes, this is working fine where you are.  I know some organizations have successfully implemented resource capacity planning.  It makes it all the most frustrating for those of us still struggling with the concept.

So what do we mean by enterprise-wide resource capacity planning anyway?  This term, while a mouthful, refers to the ability to see the resource availability and resource load of all resources in the organization and the projected load of future tasks and projects.  If you can accomplish this, then you should be able to insert a prospective project into the equation and instantly see if a) the project is feasible and b) the impact on other projects of doing the project.

Sounds simple doesn’t it?  Yes, in principle it is very straightforward.  It’s in practice that the exercise becomes a challenge.  “The technology?” you ask.  Nope.  Virtually all of the enterprise project management software vendors address this type of functionality to some degree.  The problems are rarely encountered there.  The most significant roadblocks are usually in the practices and behavior of the participants.  Here are a few areas that become a concern.

Whose resources are they anyway?

Who gets to control the resources in a multi-project environment is often one of the most contentious issues.  Many organizations use a matrix structure where any given employee will have a resource or line manager to whom he or she reports as well as multiple project managers to whom he or she will report based on project work.  A matrix organization is expected to generate some structural tension for staff as project managers vie for complete control over a person and the resource managers are expected to provide an element of balance so as not to burn every resource out on a given project.

Ok, no problem so far but this affects greatly how enterprise resource capacity planning works.  With many project managers competing for given resources, all kinds of tactics can be employed to get and keep the resources they want.  Resource managers can become just another competitor trying to get access to an employee’s time.

I’ll share if you share – maybe.

The basic premise of enterprise-wide analysis is that you’re looking at all the data.  After all, what would be the point of doing a resource plan when you’re looking at only 80% of the resource requirements and 80% of resource availability?  Especially if you didn’t know what 20% was missing.  The problem in new enterprise resource management implementations is that some project managers will be concerned that if they share their real internal data, the rest of the competitors for resources can take advantage.  For example, they might see a lull in the requirements on a given project and scoop up those key resources then not give them back in a timely manner.  If the process for this is not rigorously established (and it rarely is in new implementations), then some project managers see a huge disincentive to share.  If there is anyone who ‘opts out’ of the enterprise analysis by withholding his or her data, it can reduce the value of the entire analysis.  In a large high-tech company in Montreal, I recently challenged a group of 25 senior project managers to point to anyone else in the group with whom they shared actual project data.  0 for 25 was the result.  If people won’t share data, there won’t be any enterprise analysis.

My people are all busy beavers – honest!

In a similar vein, showing any underutilization of a resource to the rest of the project mangers can leave a project manager worried that they’ll lose that person.  Consequently, project managers who are ‘forced’ to share their data will sometimes pad a project’s requirements to show that the key resource they’ve acquired is in use 100% of the time.  There are always a few key resources in an organization that are critical to many projects.  They possess that unique combination of knowledge and skills that are at the core competency of the organization’s products and are always in high demand.  These resources can make or break a project’s schedule and often are the bottleneck that determines just how many projects can be accomplished in a given period of time.  It is, of course, these very resources that a project manager will want to get first and keep the longest.

Okay, I know I’ll be beaten, but please – not with my own data!

I’m not saying it happens where you work, but – it some places I’ve visited – there are project managers who have attempted to play fair and have given the new enterprise system complete access to their innermost honest data only to find themselves called on a carpet shortly thereafter to explain the ’significant problems’ with their project.  The evidence for these problems?  Why the project manager’s own data of course!  When a corporate culture has been used to seeing data only after careful preparation and are now plunged into seeing the raw product while it is happening, it can make managers do strange things.  If this happens once or twice, project managers will run for cover carrying their data with them.  Avoiding this requires preparing the ground in advance, talking to the management to ensure they react appropriately to the different quality of data they may now have access to.

So, is it impossible?  No – not at all.  The intense almost universal desire for enterprise capacity planning has driven software vendor after software vendor to provide better functionality to deliver this analysis.  If you are working on an enterprise-wide implementation now, the key is to not expect the software to do all the groundwork.  You’ve got a corporate culture to change and you’ll need to change it a step at a time.  Paving the way with new procedures and practices, setting up training not just for users but also for management can go a long way towards ensuring that the resource capacity planning analysis is used for the purpose it was intended and not to shoot the messenger.