Category: Computing Canada

Home Articles Computing Canada ()

Article: Project Management and Web Portals

7252413I’ve written at different times in this column about the impact of the web on enterprise project management systems.  Until now, most of that talk has been about how the availability of a web interface would attract additional users through an easier and more accessible interface.

There is an emerging movement in this regard however, which is starting to revolutionize how we think of project management data and project systems usage.  It has come about as the result of web-development from the original static html pages to a content-management paradigm where the design of the system is kept independent of the data that now usually resides in one or several databases.  In these types of systems, non-technical personnel can keep a web site full of current content and can provide a dynamic system in which many users can contribute.  This has led to a huge market called the enterprise portal web market that in and of itself is hot news.

When we apply this concept to project management, however, we find a great match of functionality to requirement.  Many project management tools have now extended their original web interface concept to provide a project management portal type of structure.  What this means in practical terms is that a project manager can provide a sort of mini-website specific to the project management office and even to specific project teams as a natural extension of information sharing.  Functionality expected in a project portal starts with an ability to add URL links to the menu structure.  This means you can immediately extend your web interface from basic schedule management to anything else you have a link for.  Additionally, document management is a common function and this means you have a stable centralized place to store all project management related documents that can be made easily accessible to all team members.  This alone can produce tremendous improvements in efficiency.

We’ve seen a coming together of several tools from different vendors.  Welcom has its WelcomHome, a dedicated project portal product.  Primavera’s recent acquisition of Evolve promises additional portal functionality from the existing web-based functionality itself. 

It is Microsoft, however, which holds a fascinating position.  In its most recent incarnation, Microsoft Project includes technology from its Sharepoint Team Services product.  Sharepoint is itself a portal product.  Microsoft Office Sharepoint Server (MOSS), the big brother to SharePoint Team Services tackles the large enterprise portal market.

With Microsoft publishing products in both the enterprise project management and portal arenas, there is no doubt that there is huge potential here for a powerful environment. 

With Microsoft Project and Microsoft Server rooted firmly in the architecture of SharePoint, even more functionality looks like it will be heading down this route. 

In the Microsoft environment, we’ve got the potential to start leveraging all data whether that is lists oriented, document oriented, data oriented or project schedule oriented.  This gives Microsoft the potential to take a serious advantage in merging these technologies to provide a significant efficiency advantage.  Microsoft Enterprise Server 2003 in particular looks like it will include much of this portal technology by default.

Aside from Microsoft, there’s no doubt that many pm software vendors will be looking to adopt portal functionality as part of their offering in the near future.

This movement towards centralizing access to data in a user-friendly interface rather than trying to integrate all the data together into one system will likely alter how project management environments are created. 

Article: Start with the simple things

7265201I’ve had a few wonderful opportunities lately to talk to high-tech CIOs about what costs them the most time.  I had thought I’d hear about project management and resource management issues.  ‘We need a better scheduling algorithm’ or ‘We need a better resource-leveling engine,’ I figured I’d hear.  Not so.  The CIOs I’ve met this month in my rather non-scientific survey talked about the simple things.

“I’d just like to know if my people are working on what we planned,” said the CIO of one of our federal departments here in Canada.  “We need to be able to track how much time our people are spending on productive vs. non-productive work,” said another CIO, this one from the IT department of a major engineering company in the UK.

When you look at this in retrospect, it’s not too surprising.  The 80/20 rule probably applies here as it does in so many things.  Twenty percent of the enterprise project functionality can deliver eighty percent of the value.  That’s certainly possible in organizations with a very new project management structure.

I get the chance to talk often to organizations about how they should proceed with their deployment of enterprise project management methodologies and I’ve always been a big fan of a graduated approach.  This allows the organization to ease-in to the change in culture while enjoying the first benefits of the project system.  These IT professionals have confirmed that this is the best plan. 

In the opinion of the CIOs I’ve just met, it seems that the most critical elements of a project system to implement are the abilities to a) inform workers what work they have been assigned and b) track where time was spent.  This being the case, many organizations are electing to look at implementing the timesheet aspect of their project system and a simple task allocation or information system to get things started.  For many organizations, just seeing where the hours are being spent is an eye-opener.  Executives are often shocked at the amount of productive time is being spent on actual project work.  I often hear expectations from management that over 80% of their employees time is being spent on project work.  Once the actual data is in, they are often amazed to find out that the number is closer to 50%.  That’s not to say that employees are shirking work.  It’s much more likely that the corporate infrastructure itself is at fault. 

“It seems silly, but the most important thing for us is to find out what work has actually been accomplished,” I was told by one CIO.  “Despite the fact that we’ve not implemented a complete enterprise project system yet, we do know what people should be working on.  Just tell me what we’re actually doing and I’ll be more effective.”

These sentiments don’t, of course, eliminate the desire for integrated project management.  That is almost universal.  Virtually all of the CIOs I talked to identified enterprise resource capacity planning as their most desirable, yet missing management function. 

So, for those of you who are still working on your enterprise project management implementations, take heart.  You can still make great strides forward by implementing the basics. 

Article: Keeping score is now a project task

scorecardMore and more these days as I visit project management offices across the country, I end up talking about scorecarding and balanced scorecarding.  These terms are part of a popular trend in management at the moment which is based on the simplest of management principles.  Scorecarding refers to simply setting goals for certain results in the business and then tracking those results on a regular basis.  (See? I told you it was simple).  The notion of balanced scorecarding carries the notion one step further to include four related categories with the corporate vision into a single scorecard.

The scores for such a process come in two flavors.  The first are subjective scores.  A manager might be asked, for example, to rate on a scale of 1 to 10 the degree of alignment of his current project with corporate objectives.  The second type is objective, something us project management types are much more comfortable with.  An objective measure is something that comes from hard data.  For example, this task finished 10% later than planned.

The process of scorecarding is of itself remarkably productive.  The simple act of looking at an objective and determining the degree of completion with that objective establishes a natural structural tension between where you are and where you want to be.  It also keeps the staff focused on what is important by continually bringing them back to the objectives being measured.  This type of thinking is, of course, no surprise to project managers.  Tracking results against a plan is the very core of project management thinking.  What is interesting, I think, is that this kind of thinking is now extending into every aspect of an organization and the objectives being measured now extend well beyond a list of tasks in a project to encompass almost every aspect of the organization.

To, I am sure, no one’s surprise, these processes have been automated into a range of products and customized software which target the scorecard entry and the display of results across the enterprise with view to providing management with advanced indicators of what is working and what is not.  Moreover, these systems are able to standardize the entry of data and the speed at which it is entered.  Reports for virtually everyone in the process from the lowest to highest employee give instant feedback on where you stand with the objectives you had, what your score is in different areas and how it compares to previous periods.

So, what does this have to do with enterprise systems?  Well, there’s not much one can do about automating the subjective scores, they’ll always have to be entered by hand but the objective scores is another matter altogether.  Implementers of scorecarding systems look with a hungry eye to centralized data systems such as the corporate ERP or HR systems.  The data in these systems provide great sources of information that can establish without argument the score for a particular category.  The movement towards enterprise project management systems is now providing a new and exciting source of metrics which can deliver automatic results to the scorecard system.

As interesting as all this is, there is something else to consider in a scorecard or balanced scorecard environment and that is what you should be scoring.  Choosing the metrics which represent the elements of the organization which most affect results takes the eye of an experienced expert.  So move forward with an open eye when you’re looking to keeping the right score.

Article: “Agile” project management for a changing world

excel-project-management

Here’s a number that I heard recently that, although it didn’t surprise me, is a shocking number to deal with.  It turns out that there are an estimated 40 million people on the planet who use Excel for project management.  As a percentage of the total number of people who must use PCs it’s probably not a huge number but as a percentage of the total number of dedicated project management applications sold, it makes Excel the most popular project management product on the market today.  You have to wonder what the attraction is.

When you look at project management packages in the market it becomes apparent quite quickly that they are feature-rich and require some level of expertise to take advantage of.  How many of us are using less than 25% of the functionality of our pm software?  Have pm software vendors missed the mark?  Are packages like Microsoft Project too complicated to be successful?

Not that long ago, pm software vendors used to think that the fundamental problem in the market was lack of training.  If only end-users were intelligent enough to understand what we could do for them, they’d surely implement an integrated high-end system.  Training, we all thought, was the best answer.  The market taught us differently.  It turned out that users didn’t want to be trained to use more complicated systems; they wanted systems that were easier.

The first wave of this has really reached its maturity level.  The domination of Microsoft Project as a desktop tool was largely successful because of how quickly end-users could produce their first results with the product. 

The next wave of pm software is underway.  Now, enterprise systems from numerous vendors are splitting the end user experience between a fully functional desktop tool and a much, much easier to use web-based interface.  It’s true that these systems involve more work to deploy but the end-results can be in an organization which must manage multiple projects with numerous resources  The newfound interest in the Project Management Maturity Model lends itself perfectly to these systems as the model is all about moving from ad-hoc project management to an integrated process.

But this leaves out the 40 million people using Excel.  There’s still a huge market for project managers who are most effective when working in an ad-hoc manner and have no desire to operate in an integrated view.  While meeting with Fujitsu Consulting last week, one of their managers coined the term “Agile” project management.  I very much like the concept.  There is no doubt a significant market for a project system that is even simpler than Microsoft Project Standard.  It would have to be low-cost, stunningly easy to use would have to be able to go from insert disk to useful output in a period measured in minutes, not weeks.  I know there are already products trying to target this market (Milestone comes to mind.) but these 40 million+ users are still not finding something that makes a sensible return on investment for them and I’m sure we’ll be seeing more attacks on this end of the market over the next year or two.

Now, lest someone worry that I’ve given up on my long-standing interest in enterprise project management, fear not.  But I’ve always believed that systems should serve a purpose and this category of ad-hoc project management is still not being adequately served.  Enterprise project management and moving to an integrated system only makes sense if it returns sufficient value on the investment of time and effort to deploy it.

 

Article: Maturity comes to Project Management

pm_maturity_4001It’s quite the buzz in the project management industry at the moment and it goes by the name of the “Project Management Maturity” model.  If you’re wondering if this is a relative to the IT world’s Capability Maturity Model (CMM), you need wonder no longer it’s a not-so-distant first cousin.

 

The idea of the PMM is that an organization’s capabilities of managing project management are assessed at a range of different levels.  There are several flavors of the model floating around but the most common iteration shows five different levels at the moment.  Labels vary but for the sake of conversation let’s number them like this: Level 1: Ad-hoc, Level 2: Planned, Level 3: Managed, Level 4, Integrated and Level 5: Sustained.  Ad-hoc is where you’d expect most organizations to be and you’d probably be right.  This means that project management occurs project-by-project in a non-standard manner.  Planned means that there is some standard for the planning aspect of project management at least but that tracking the project is done on a project-by-project  basis.  Managed would indicate that there is some normalization of how projects are both planned and tracked.  Integrated means that there is a method which brings the project management process and data together for all projects in the organization.  Sustained would mean that there is a reiterative process which would self-correct, self-improve and that the process would be self-sustaining.

I bring up the subject for two reasons.  First, there is a lot of activity in the industry at the moment doing PMM assessments, PMM implementation plans and PMM improvement projects.  So, if you’re not yet involved in such an initiative, you might expect to be soon.  The second reason is a little less obvious.  It seems that one automatically accepted aspect of this whole concept is that it is, of course, better to be higher on the scale.  I’ve been in meetings recently where this 5-level chart is put on the wall and a senior executive is informed that an assessment of the organization has determined that it is at, for example,  level 2.5.  You might just as well wave a red flag in front of a bull.  “Why aren’t we at level 5?!” the executive demands.  “I want to see a plan to get us to level 3 as soon as possible!”  Why?  Because 5 is obviously better than 1. 

It’s worthwhile to note that you can make a case for any one of these levels being appropriate for any particular organization.  We spend a lot of time talking to people about enterprise-wide project management in our firm but epm simply isn’t appropriate for some companies. 

You’ve always got to think of the overall return on investment.  In some organizations, the difficulty in implementing the culture change required to do epm outweighs the potential benefits.  In others, the shear diversity of the types of projects managed means that epm doesn’t return much investment at all.

For some of these organizations, being at a level 3, 2, or even 1 will be the most effective choice.

So, if you’re doing a PMM assessment at the moment, by all means, continue.  It’s always good to know where you stand and introspection almost always returns good value.  But, before you jump on the bandwagon to see how high up the PMM ladder you can get, make sure that the benefits are there.

 

Article: EPM stands for Effort Project Management

project_management

In 1994 I wrote an article outlining a disturbing trend in project management systems deployments.  At the time, there was a significant movement away from large-scale project management systems to PC-based systems.  The movement had really started in the mid-80’s with the rapid adoption of the PC as a work tool but the release of Windows had spurred the sale of project management systems as never before.  The original high-end project systems of the late 70’s, I wrote, cost in the hundreds of thousands of dollars and clients thought it quite reasonable to spend that much again on training and configuration.  The problem was, the systems of the 90’s cost only a few thousand dollars or less and the general reaction of clients I met was to spend an equivalent amount of money on training comparative to the value of the software rather than the training that had always been required.

I bring up the subject because of the recent advances into the enterprise project management domain of Microsoft.  There is a newfound interest it seems in bringing the enterprise together to manage projects and Microsoft is at the very forefront of that interest.  With the release two years ago of Project Server 2002 and the release of Project Server 2003 last year, Microsoft delivered a product that can be deployed as a enterprise project system.  What’s fascinating about the release of this product into the marketplace is the way people are going about using it to deploy Enterprise Project Management.

First of all, there’s no question that the concept is desirable.  Virtually everywhere I go from the smallest to the largest organization, there is a need to bring project information together and to strive for making better decisions about projects across the organization rather than project-by-project.

The legacy that Microsoft carries however isn’t helping it.  Microsoft has become known in the application business as a company that provides low cost project management software to the individual.  In virtually all of Microsoft’s applications, the expectation is that you’ll be able to quickly install the product yourself, configure it immediately and then be able to start producing results instantly.  The Windows versions of Microsoft Project all held to those principles.

Now, along comes Project Server and the ability to work across all projects at once and to group projects by portfolio and to collaborate with team members and PMO personnel alike.  Sounds like a match made in heaven, yes? 

Sorry, no.

The issue is the same as in 1994.  When considering the deployment of Project and Project Server, many clients bring their legacy of experience with Microsoft to the table.  In a recent conversation with a very high-tech firm, I helped scope out a deployment plan that called for about 4 weeks of configuration work including mapping processes to Project and then another 3-4 weeks of training for the 200+ personnel involved in projects who would have access to the tool.  Of the total, only about 2 days were involved with installation.  The project manager was stunned.  “I had figured on 3 to 4 hours,” he replied.  “with maybe a day or so more of training.” 

We’ve now seen numerous scenarios where an organization does a minimal epm effort and ends up having to go back and do it again, this time with less credibility with management.

The need for configuration and training shouldn’t be a big surprise.  When the same project managers are asked about any other major enterprise system such as ERP or CRM, they acknowledge the extensive effort that will be required to implement change.  Perhaps it’s the shoemaker’s children going barefoot syndrome where project managers can’t seem to apply the same logic to their own systems.

Maybe the solution to the problem is much simpler.  We should ask Microsoft just to add two zero’s to their project system pricing so we can take it more seriously.

Article: Be sure the cure is what you want

woman-on-phone2

Years ago I had the occasion to attend a fascinating seminar about getting what you really want in life.  As an object lesson at one point, the leader offered to dissipate the headache of anyone who had a headache and who wished to get rid of it.  I won’t bore you with the procedure although I did see the demonstration done multiple times and with 100% success each and every time.  I was reminded recently of one of the key elements of the demonstrations which, I think, is pertinent to anyone doing an enterprise project management systems implementation.  Once a willing volunteer had been selected, the leader made a special point of asking them if they were willing to have their headache disappear.  This wasn’t a casual question, they said.  This was critical to the demonstration’s success.   The volunteer was asked to think about it for a moment to be sure they were willing to rid themselves of this headache.

I’ve been thinking lately that I should be doing the same thing with some of the larger organizations I consult about deploying enterprise project management.  Given our business, we’re almost always talking about the more technical aspects of such a deployment; installing epm and enterprise timesheet systems and configuring them to match a corporate epm process.  The problem seems to come up time and time again as we get near the end of the deployment and the system and/or process is about to go live.  Suddenly there is a burst of resistance from different sources and a pause as the epm project team considers what they’ve gotten themselves into.

It’s not like epm systems and epm processes don’t work.  They do.  There is plenty of evidence in case study after case study.  The problem is more that these projects are inevitably considered technology projects rather than change-management projects and, despite the advice of everyone involved, changing behaviour and culture is infinitely more difficult than installing software.

Moving an organization to work together in any aspect of its business is a challenge.  This is certainly so when we talk about project management.  The benefits to management of having data all gathered together seem obvious but the costs are not always apparent.  There is no question that deploying epm will always be a trade off. 

Ok, that sounds perhaps strange coming from someone who has been an evangelist for epm for 20 years or so but it’s true nonetheless.  Sharing resources makes for a great demonstration and, in a perfect world, seems like an obvious solution but there may be a penalty as project managers who have been able to successfully hoard resources by flying under the radar are now pushed to work at the same level of effectiveness as less efficient project managers. 

Having everyone see global data may seem excellent until you find that there are some who will use the opportunity of more data access to spend more time lobbying by using the data of other project managers than working on their own. 

Left unmanaged, it is certain that an epm system has the potential to make an organization less efficient rather than more.  John Chambers, the CEO of Cisco Corp. had a study commissioned where the effects of automation and the effects of process change were studied.  In some cases, the study found, automating then changing the process actually caused decreases in efficiency of up to 9%!  On the other hand, adopting a new process and then automating it caused increases in efficiency of up to 21%. 

The lesson is really one for me and people like me who work with organizations who want to implement enterprise project management.  When an organization says they’re ready to solve their problem, I’ve got to ask: “Are you sure you want the solution?”

Article: Project Management – Will you do what it takes?

olympic-rings1

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?’

 

Article: Portfolio Management – Choosing the right projects

woman-on-phone1

It’s the latest, hottest topic in the project management workspace – “project portfolio management”.  At one time, what we meant by portfolio management was simply the management of multiple projects at one time.  The old term “multi-project” management referred to doing critical path and resource analysis and reporting of multiple projects grouped together.  Nowadays, the term often has an expanded meaning to include the authorization process of the projects themselves, a topic which is particularly interesting not only to me but also to executives everywhere.

When you think about all the statistics we’ve quoted in these very pages about projects that fail, I’ve long held that half the battle in improving these statistics is in affecting what projects were chosen in the first place.

If you’re a project manager, you might think that you have no influence over choosing projects; that they’re often handed to you with unworkable conditions as a fait accompli.  Nothing could be further from the truth.  Implementing a project approval process or “gated” approvals is the kernel of project portfolio management and it’s almost always initiated by the project office.  We don’t need to implement rocket science here.  Let’s start with the basics.

First, let’s establish an approval flow for new projects.  The first phase or “gate” could be the authorization to create a detailed plan.  This makes some sense as creating a detailed plan takes effort and/or money and expending effort is something that is almost always approved by someone.  The creation of a simple form whether on-line or on paper in which some basic criteria are established such as expected return on investment and alignment with business objectives. 

Once the detailed plan is created, it might have to be attached to a form with identified risks, bottom-up estimate of schedule, effort and costs. 

The combination would provide a baseline from which to measure if the project passes this approval.  Being approved through this second “gate might allow the project to begin execution.  Approval might include a calculation of return on investment based on the updated schedule and costs.

Regular reviews of the project status could be implemented in the same fashion, allowing the project to be ongoingly evaluated against a dynamic economy and changing business conditions as the project progresses.

A simple gated approval process can make a tremendous difference in a number of different ways.  First of all, just going through the process identifies risks and assumptions that might otherwise be ignored.  Management might have an assumption that a new product could be developed within a certain amount of time and for a certain amount of money.  The ground-up estimate might show that the product can’t make it to market in the time required to pay back the results expected.  Another common assumption is that key skilled personnel will be available when we need them but in the high-tech world there are often a very small number personnel that are so key that they can form a bottleneck to new project schedules.  Doing a skill assessment in our baseline and comparing it to existing projects will likely reveal the problem.

It’s no wonder that project portfolio management is such a hot button with management in this tighter, less forgiving economy.  The good news is that starting portfolio management by implementing a very simple approval process is possible with minimal effort in almost every organization.

Article: Breaking down the epm business benefit

philosophy

I was asked recently to help an organization prioritize its enterprise project management deployment. As we’ve often suggested here, the organization had done some homework. They had assembled a multi-departmental team to determine the aspects of epm that they considered important and they had worked over a series of months to articulate their process and to evaluate potential software vendors. They had determined that replacing an in-house timesheet system with a new timesheet system that would improve the time and billing process was their highest priority and had already purchased several hundred licenses of this time and expense system.

Sounds like there was nothing for me to do, doesn’t it? The organization had called me in because the scope of the deployment had recently undergone a significant increase and the head of the team was quite concerned that their entire plan was now at risk. The original scope had included several aspects of epm functionality including, of course, the timesheet but also a complete Enterprise Project Management system for resource capacity planning, schedule tracking and more. The selection of the timesheet system included, in part, the ability to link to Microsoft Project, which had already been targeted as the preferred epm system. The original plan was to deploy the timesheet first over a 4 month schedule then work on the epm deployment in the months following. Somewhere along the way, two things happened to dramatically alter the schedule. First, the timesheet vendor informed the client that a perceived deficiency in the abilities of the timesheet could be solved with the functionality of the epm system and second, almost simultaneously, management had renewed its requests for resource capacity planning information from Project.

The result was to move the implementation of the entire epm system forward and to implement the timesheet system and the epm system simultaneously. I was not particularly surprised to find that the schedule had not been lengthened at all as often happens during ‘scope creep’. The challenge I was asked to solve was to determine if the schedule was still viable and to look over the new scope of work to determine if this was the most effective course.

I mention all of this because the exercise we did together with this client is one that is done all too rarely in deployments of epm systems. We looked together at the final vision of the system from a business needs perspective. I asked the deployment team to identify business decisions they intended to make from the system rather than to identify a list of functions that they thought they would need. By focusing on the intended business uses of the system we were quickly able to list the expected business benefits.

The resulting list was highly relevant to their request. Over a couple of hours we were able to list the majority of the business benefits they were hoping for and the actual business decisions they expected to be better able to make once the system was deployed. Interestingly, virtually 100% of those benefits were focused around the functionality of the timesheet change rather than other epm oriented functionality.

This left us with the problematic functionality that had started the whole change in scope in the first place. ‘Who had reported the problem?’ I asked. The culprit was the chief accountant. An hour later we were meeting with him. Yes, he could confirm that this function was something he desired. However, when I asked how much effort was required to manually (ok, via Excel) manage this function now, the answer was ‘about 5 minutes or so per month’! Needless to say, with such a small improvement in efficiency as our expected benefit, the cost and effort of the whole epm deployment for this one function couldn’t be justified.

The lesson for all of us is to focus on the Return on Investment for each aspect of your epm deployment. What will be the intended business benefit and the intended business use of the system? Make sure you know how going through the exercise of deploying a whole enterprise project management environment will pay you back dividends.