It’s the hot button lately in project management circles. How can teams collaborate? It’s not idle chatter. It’s been apparent for a long time that a project manager’s role is not just calculating a schedule from his hidden laboratory deep in the bowels of the organization. Now a project manager is expected to spend the vast majority of his or her time working with others. They may be negotiating with the clients or recruiting new team members or empowering and encouraging the team to be more effective or referreeing resource conflicts with resource managers. And that’s just one-on-one or with small groups. The project manager is also expected to speak publicly to the board or the media or the users or the team.
With collaboration being such a hot button it’s not surprising that project management software publishers and consultants are happily explaining how wonderful it will be for clients to improve their collaboration tools. I get such requests on a regular basis.
So let’s pause a moment and just review what collaboration means and what implementing better collaboration entails. Dictionary.com has a couple of definitions of collaboration but the most useful to this discussion is: “To work together, especially in a joint intellectual effort.” Not too useful for practical purposes but the idea is having people work together. Well, a project almost always involves people working together so we know we’re off to a good start. What might team collaborators collaborate on?
A few categories of how teams might work together might include document management, meeting management, communications follow up or working with virtual teams. Let’s tackle a few of these:
One of the most popular things pointed to when talking about collaboration benefits is document management. In many project environments, moving documents around numerous participants in the project team can be a critical success factor. In high tech, these might be design criteria. In engineering, they might be archtectural plans or engineering drawings. In bio-research they might be regulatory documents. It seems attractive to link these documents to task reports when doing project schedule reports but the big benefits of this kind of collaboration process is managing the workflow of the document. Should this be part of your project management process along with schedule management? There are a couple of factors to consider. First of all, does your organization already have a document management system. Many large organizations do. If so, then going with the flow on a system that’s already deployed makes a lot of sense. Secondly, does your entire project team have access to it? This may not be so obvious. Many project teams extend beyond a single organization. If that’s the case, then setting up a parallel document management system for documents associated to the project might be more sensible.
Meetings, Meetings, Meetings. They’re so common that many timesheet systems automatically include a meeting entry. (We get asked for one all the time with our own TimeControl timesheet deployments.) Having meetings is often collaboration by definition but how you conduct those meetings can make a big difference to the effectiveness of a project. Meeting management systems include numerous features such as agenda management, minute taking, meeting collateral management (such as reports that are submitted to be viewed by the partiicpants), attendance recording and even virtual attendance for those who are out of town. With so many organizations having to curtail travel and even inter-office movement in order to save costs and with so many project teams reaching outside the organization, an effective meeting management process and system can make a world of difference. Sometimes such meetings can have an immediate impact on the project inlucing changing priorities, changing resource allocation, updating risks and progress information. Just being able to record promises made in a regular project review meeting and being able to recall that information instantly at the next meeting can revolutionize project progressing. But, does this mean that that the meeting management system should be integrated into the project scheduling system? Possibly. The first place to look is to see how the meeting management process is integrated into the project management process. Then look and see if there is an existing meeting management system and if that system is available to all your participants. It might be more important to have meeting management linked to document management than to scheduling.
More and more we’re seeing project teams being defined outside of the walls and even the corporate organization. Teams might include the client and sub contractors and even regulatory authorities from outside the organization and executive sponsors and resources from within the organization. The team may extend not just beyond the walls of the organization, it might also extend into numerous time zones and even numerous countries. Just holding a telephone conversation can be a significant challenge if part of the team is just getting to work in the morning as another part is just leaving at the end of their day half-way around the world. Empowering the virtual team to work as a team can be a significant challenge that has to be addressed early in the project lifecycle. Being able to distribute documents, record virtual meetings for review by others offline, updating progress in multiple time zones and even just being able to deposit project deliverables and artifacts somewhere in a file management system that is managed and traceable can make the difference between a project that works twice as effectively or half. I have seen such virtual teams hum along at a breakneck pace, one group half way around the world is delivering aspects of the project that is being reviewed by a team on the other side of the planet in time to be updated by the first group as they return in the morning. It can move so fast that it feels like around the clock development and that too can pose a challenge. When the pace of work is twice as fast as some team members are used to, the project can go off the rails in an awful hurry. Systems need to be twice as vigilant if the work is moving twice as fast so deploying systems to allow that tracking to be done more effectively is essential.
Incident and List management
There are so many bits of data that get generated during a project that having a single place to track them can allow many people to connect quickly and effectively. Lists and artifacts can be almost anything. They might include commissioning lists, deficiencies, bugs, corrective measures or even just lists of team members. Having such information readily available to all team members can be a blessing. I’ve seen a number of projects where integrating such list management into the project system and having that system be outward facing; meaning available through the Internet improves the speed of managing those lists and identifying problems that must be addressed by other team members. Simple online list management can level the playing field quickly by allowing required intervention to be recorded that reaches any member of the team at any level. A process needs to be in place to prevent every team member from assigning incidents indiscriminately to executives but the ability to do so can make a project tremendously more effective. These lists are rarely at the level of tasks that are managed in the schedule yet they often are able to affect tasks in the schedule.
Communication with… everyone
Effective communication is everything to a project manager but when setting up your project environment its worthwhile to try to determine what kind of communication is appropriate for what kind of information. Will you be checking your FAX every hour? Is that how you’d like to transmit documents? Do you want everyone copying everyone on every email? Will you progress data in a physical meeting or can members dial in virtually? Will you be updating information via SMS on a cell phone or on an application on a smartphone? How about instant messaging? Just because you can instant message someone on their phone will you use this as a primary source of communication? What information should require instant messaging and if you’re going to use this does everyone on the team have access to the same instant messaging system and network? Figuring out your communications strategy before you start your project makes a huge difference.
Collaboration is a way of life in today’s project management world. Most project managers and project management offices don’t need a do-everything project management system but hoping that collaboration will happen by default is a fantasy. A smart project manager will organize how they want collaboration to happen before the project starts even when systems are already in place. Getting everyone onto the same page early often makes the difference between staying ahead of the project or living in reaction mode trying to catch up until the project is done.
Executives often ask me for the impossible and what they want is best exemplified by an often used phrase, “A sip from the firehose.” In most organizations today there is no shortage of data and in the project and portfolio management realm in particular we have a plethora of systems and processes that can generate data but no manager can possibly sift through thousands or even millions of records in order to determine what decisions they should make.
The result is that most significant decisions about projects including the decision to start the project in the first place is made on an ad-hoc basis.
The technique to avoid this is well known. Organizations should choose “Key Performance Indicators” (KPIs )which will surface information that is critical to making those business decisions. But, how does one choose those KPIs? How do you know that the KPIs you’re using are producing the result you require? Let’s take a look.
First of all, where do we look for choosing the right Key Performance Indicator and how will we measure it? These metrics will be used in a variety of ways. We can use these metrics for distinguishing one project from another. We can use them in the project selection process, the stage gate process, the resource priority allocation process and the project review process. There is no limit to the number of things we could measure.
One place to look it through the main elements of PMI’s PMBOK (Project Management Body of Knowledge). In each section you might have possible measure that would lead to better management of the project.
In the Scope area, for example, you might have scope creep or scope change as a measure. In the Time area you might look at delays in the schedule. In the Cost area you might look at resource costs or Return on Investment. In the Communications area you might look at the timeliness of schedule updates or the status of project reporting. In the HR area you might look at Resource Variance or Resource Load/Overload or Resource balance. In the Risk area you might look at the volume of risk items and their severity or urgency and so on and so on.
Not every metric will make sense in every context. For example, in a private organization, projected Return on Investment might be a critical measure. In a public organization this might be completely inappropriate. There, citizen satisfaction or alignment with legislative requirements might be much more appropriate.
Some of the criteria for a good KPI would be this:
Ø The KPI reflects some element of corporate strategy
So, measuring ontime delivery might make sense in most organizations, but where corporate strategy is more focused on quality or safety, focusing on ontime delivery might result in management making decisions that are diametrically opposed to the corporate mission.
Ø The KPI is actionable
All too often we see organizations with spectacular dash boards containing lovely graphics and charts and, when we ask what action is supposed to happen if this indicator turns red or if the needle on that guage goes to the danger zone, no one knows the answer. The whole point of a measuring and reporting on a KPI is to ultimately take action.
Ø The KPI should result in obtainable objectives
Creating a metric which no one ever has a chance of getting out of the “red” and into the “green” makes no sense. It results in urgent emergency action day after day after day and ultimately is self-defeating. The objective that the KPI represents (overload less than 110% of availability for example) must be attainable.
Ø The KPI should be measureable
It’s tempting to make KPIs which are wholly subjective, where someone just plugs in a number or a color. If this is based on a feeling rather than some empirical measure, the KPI typically has little value and yet the decisions made on the basis of the KPI may be just as significant as those based on other empical measures.
Ø The KPI should not be duplicated
Just because we have a dozen different ways to display late schedules, showing all those KPIs doesn’t add value. In fact, it can be confusing and disruptive.
Ø And finally, the KPI and the actions associated with it should be understood by all decision makers. Having a common understanding among all the decision makers of what a particular measure and indicator means is critical to using KPIs effectively.
There are a number of easy mistakes that people doing this exercise for the first time face. Here are some of the most common:
Ø “Great news, I have hundreds of KPIs!”
This isn’t great news at all. Remember, what we’re after is a sip from the firehose. If you open the tap too far; if you let too much water through the hose, you’ll knock management from its feet and they won’t be able to absorb the information. Typically we look for a handful of KPIs. As Chris Iervolino, an expert in Business Performance Management (BPM) said, “Somewhere in the extensive negotiations of creating the KPIs, the ‘K’ got lost.” So, just because you can measure a thing, you don’t need to measure it.
Ø “Great news, we have only one KPI!”
Having too few KPIs is also not useful. There are always a couple of opposing forces and results that can be identified in the project management business and the whole point here is to make business decisions. Those opposing forces need to be identified and displayed in some way.
Ø KPIs are too subjective
There’s a strong incentive to invent KPIs for which there is no measure; no metric. The result is an indicator behind which is just a subjective decisions based on someone’s feeling or intuition. While many business decisions are made on a manager’s intuition, when we put subjectivity into a Key Performance Indicator, we take a subjective perspective and display it as an empirical or data-sourced result. The effect of this can be negative.
Ø The KPI has questionable completeness or quality
Imagine that we have a Key Performance Indicator that shows our resource capacity. The graphic shows the organization’s current status of all work and all resource availability and projects the expected over or under load of resources against our project and nonproject tasks in the future. But the indicator only has current project data for 20% of the projects. Another 60% of the project data is at least 30 days old and 20% of the data is missing altogether. Imagine what business decision might be made on the basis of this indicator alone and how potentially damaging that would be. When KPIs are displayed, we always recommend that there is some indicator of the indicator’s quality and the completeness of the underlying data.
The great news about applying the Key Performance Indicator paradigm to project and portfolio management data is that there’s typically lots of great data to choose from and the nature of the project management process results in a lot of that data being of very high formalized quality. That’s perfect for a productive KPI exercise.
If you’re getting started on choosing your KPIs, the best advice I can give is to start small. Start with 3 or 4 indicators and get the measurements of them, the display of them and the actions associated to them right. The benefits of doing this can be profound and don’t worry, you can always expand the number of indicators in the future.
At least once a week I must get a request from an organization to advise them on how to proceed with a Proof of Concept for epm software. It can be for a wide variety of epm tools and the particular flavour isn’t relevant to today’s conversation. My approach to all of these requests is the same and it often makes the requestor take pause. “We’d be delighted to help with a Proof of Concept,” I’ll say. “Please describe to me exactly what you wish to prove.”
It’s an obvious question isn’t it? Yet, in less than 10% of the cases, does the requestor have an articulate answer. I’ll get a hundred variants on “We want to see if it will work for us.” or something to that effect. When I poke in a little deeper to find out what the person really wants to accomplish, there is a disturbing but remarkably common theme. In many, many cases, the person who is trying to do a proof of concept is hoping that they can quickly establish a working project system with the enterprise tool and that management will be able to see this miraculous tool working and providing such remarkable value that they will grant the hitherto unavailable budget for a complete deployment.
Unfortunately, trying to use a Proof of Concept deployment to convince management to commit to epm or an epm tool is almost never successful. There are a couple of problems that may not seem obvious.
First of all an epm deployment, even a tiny one that you may be thinking of for this Proof of Concept requires the support of management to have any chance of success. A deployment of epm is a tiny bit about technology and a huge amount about changing behaviour or culture change. Without the direct and unequivocal support of management, you may get the technology installed but you have no chance of effecting a culture change. This is true for a 10 user deployment as much as it is for a 1000 user deployment.
Also, some of the most popular objectives for an epm deployment such as Resource Capacity Planning simply can’t be delivered until all data is in the system. Oh, you can simulate it of course, and you can certainly show an example report but you can’t see even 1/100th of the possible value with only a tiny percentage of the data. Moreover, without management ready to demand that all users commit to the system, there is little chance of getting access to all the data anyway.
Doing an epm deployment which has a chance of producing any real value for the organization, is going to first require a period of time where senior management examines and then commits to the results they hope for from the system. We usually do this work in a vision session of some kind early on in the deployment. Without knowing what business drivers the system is expected to affect, we are in the dark as to what the epm deployment is hoped to accomplish. At best, we must use guess work or hit-and-miss targeting to hope that we find a function in the system that somehow touches a business driver an executive is committed to.
No, using a Proof of Concept for this purpose may be one of the least effective manners of getting management to commit to epm. There are numerous other alternatives. If you want to get management to get on board with your epm system plans, here are a couple of suggestions:
One of my favorite methods is to do a facilitated vision session. Both senior management and the senior project personnel usually attend although sometimes not together. The beauty of this plan is that the investment in actual money is usually very small. A vision session for epm can usually be accomplished in a couple of days. There is often some preparation work and always some post-meeting documentation but still, the investment of both time and money is comparatively minimal. The other great thing about this strategy is that no matter who the ultimate system vendor is, the exercise with senior management is never lost time. Working through the business drivers for the epm system is a critical first step and, the worst case scenario is that management and the project personnel discover that they’re not ready to commit to epm at this time.
Another strategy is to use one of the many Executive Circle types of events for management to find out more about these systems. There are events of this type hosted by almost every epm system vendor but also from associations like the PMI or others. For example, the American Management Association has recently taken a more significant interest in project management and executive seminars by this group would be a great way to introduce the concept.
Visits to other organizations that already have epm where your executives can meet their executives are also tremendously effective in this area. Not only can your executives hear about how the epm system worked for another company but they are often quite gratified in being able to network and share concerns of all types. EPM system vendors can almost always broker this kind of visit for you.
Now, if you’ve gotten this far into the column and you’re a little ticked because you don’t actually fall into this category and your proof of concept plan falls into that 10% of cases where you do know what you want to prove, well fear not, I haven’t forgotten you.
If you actually are proceeding with a Proof of Concept, here are a couple of tips to making it successful.
First, make it a project. I know it sounds silly saying this to project people, but you’d be surprised how often this kind of thing isn’t managed as a project. Do everything you’d do with any other project. Have an executive sponsor, get a budget, make a schedule, have fixed objectives. If you don’t do this, you can end up with a proof of concept implementation that drags on for months or even years. (I’m not kidding. I’ve seen such implementations go on for more than 2 years!)
Next, make sure you have not only created some objectives but also some measurements that determine what will constitute a pass or fail of the implementation. Did it do what you needed? If so, move on. If not, once you’ve exhausted the avenues available to you in making it work, close that aspect down and get to the next step.
Regardless of whether you’re looking at convincing management or proving technical functionality, make sure your Proof of Concept has a beginning and an end. Remember to use the right tool for the job. If you are using a Proof of Concept as a tool, it works best at proving something specific rather than convincing someone of a general concept.
Well, we told you it was coming and now the release of Microsoft Project and Project Server is just about upon us. On May 1st, Microsoft’s Enterprise clients and its partners will be able to access the official release of Microsoft Project 2010 and Microsoft Project Server 2010. While the official name of the products has dropped the word “Office” (It was quite a mouthful), both products continue to be part of the Microsoft Office family of products and will be released at the same time.
That’s not an accident.
Microsoft has made it quite clear that its strategy is to leverage client’s interest in one product line by tying it to another. The Office group has done this very successfully. You don’t think anymore of just buying Word or just buying Excel. No, you buy one of the bundles of Office and those products are contained within it.
Project and Project Server will continue to have their own licneces and aren’t available as part of any of the Office bubdles for now but there a bunch of other things that have changed.
Say bye-bye to Office Project Portfolio Server
One big change is how Microsoft has rolled some of the most popular Portfolio Selection functionality from Portfolio Server 2007 into Project Server 2010. There will not be a Portfolio Server 2010 product and, while existing users of Portfolio Server 2007 will see updates of that stand-alone product for some time, any new development on Portfolio management will focus on Project Server.
Did you say 32bit? Bite your tongue!
It’s all 64 all the time for server installations now. Installing Project Server will no longer be possible on a 32bit version of Windows Server. The new 64bit architecture makes a lot more memory available to Project Server but may cause some companies to take pause as the consider the costs of hardware.
Project Standard and Project Professional will still work on both 64bit and 32 bit versions of Windows Vista and Windows7.
Gotta love SharePoint
Previous versions of Project Server could be installed with either the free Windows SharePoint Services (WSS) of the licensed Microsoft Office SharePoint Server (MOSS). (Don’t you love how many acronyms we use in this industry?) Project Server will require users to have a MOSS license. The system will now longer support just the free WSS. This may be a license cost issue for some users.
So that’s the bad news. What’s the good news?
There’s good news in this release in a couple of areas. First of all, the underlying architecture of Project Server and Project Desktop hasn’t changed since 2007 and that will almost certainly mean the stability of the product at release time will be better than 2007 was.
Rather than rewriting the system’s architecture, there are new features that should be popular including Project Data Pages that allow Project data questionaires to be gathered online and then woven into a workflow, some improvements in the timesheet that will be great for those tring to do a full timesheet week and then update the project progress, some easier dashboarding tools that should allow people with intermediate skills to create great graphical representations of their data and, of course, the aforementioned Portfolio Selection functionality.
On the Desktop look for a distinction between Project Standard and Project Professional that will no doubt result in some kind of push to have people upgrade to the more powerful version.
Project Professional will have a new Timeline View and a new Team Management view which I think will go over well.
The scheduling tool will not default to automatic scheduling and you’ll be able to enter a description rather than a duration iin the duraton column as a sort of placeholder for the data to be entered later. Purists may howl at this. It’s another sign of how Microsoft Project has become so ubiquitous and how the product must now cater much more to non professional project managers.
Expect the Microsoft marketing beast to crank up to a fever pitch in the coming weeks. It’s already been moving forward at a pedestrian speed for months but as the product hits the market, Microsoft will do what it does best as it announces everything new in the Office 2010 family of products.
How can this happen? After all, those of us in the project management industry tend to think of project management as most critical in difficult times and there is plenty of evidence to show how projectized organizations generate tremendous levels of efficiency.
To figure this out, it’s important to think of how organizations come to be in the first place.
Organizations usually get started from an entrepreneurial spirit. Company founders use family or trusted advisors to take over key elements of the company because it’s too big to do alone. This historic perspective continues into modern day accounting and business management. Organizations are traditionally organized by function, not by result. Look at any standard accounting chart of accounts and you’ll see department oriented thinking. Look at standard budgeting and it is department organized.
So department heads have traditionally had ultimate power, thinking of themselves as the heads of their own companies within companies. That’s great right up to the point where the products the company needs to create must cross these departments in order to be completed. And it is in answer to that challenge that today’s matrix organization came about.
The Matrix organization theory is relatively new but has been almost universally accepted in organizations that do projects. The idea is that projects move across departments. The power in the organization is now shared in some manner. Department heads are still responsible for their people but the project office is responsible for producing the result. Many modern day managers have grown up in world where they’ve only experienced Matrix structures in the organizations they’ve worked in. But, is matrix management automatically the most effective path? Opinions vary.
In a perfect world, the two axes of the matrix are intended to balance each other out. We’d expect that an organization that is completely oriented to the organizational axis of the matrix would have very happy employees who were well taken care of, highly trained and well compensated but would not get a lot of project throughput. Conversely, we’d expect that an organizations that is completely oriented to the project axis of the matrix would have lots of projects being completed but would be burning out staff on a regular basis, having lots of turnover and ultimately would lose its key resources. The idea of a matrix organization is that it is conflict by design. In a matrix organization we expect the two axis to push against each other with the intent being that we will find a perfect balance.
There are two big problems with this assumption however. First, not all people are created equal. Every organizations has some managers who are more articulate, more experience more forceful, more networked, better at negotiating and better at internal politics than others. Those people who are less experienced, less connected and ultimately less powerful will suffer by comparison. The second challenge is much more significant. The traditional position of the PMO is often one with lots of responsibility but little authority. Authority rests almost always with the organizational aspect of the matrix. So, when an organization is put under pressure (as happens in a tough economy) those people in authority are pressed to protect themselves. The result is often the exact opposite of what would be good for the organization.
In the economic pressures of the last couple of years, we’ve seen a number of organizations where the role of the PMO has been degraded. It’s exactly the opposite of what you’d expect in a challenging economy. We’d expect that this would be the time where the most throughput possible would be the incentive and, to be sure, in some companies that’s the case. But, in some organizations, the pressure on the organizational department managers is to grab back as much authority as possible. These groups create their own project management groups that are specific to their departments thus paying lip service to the project management requirement but at the same time removing the most powerful benefit to the organization overall: the ability to manage work across departments.
This is most common in the largest of organizations where the size of the matrix is tough to comprehend at the best of times. The end result is a weaker and weaker PMO until in the end, the PMO is, in some cases, dissolved completely in favour of “department PMO’s” which, of course manage projects only from a hierarchical perspective; that is to say, only for their own departments.
It’s a complete return to silo management by department.
If this is something you’re experiencing and you’re responsible for the project aspect of the matrix, there are a few things you can do.
First, market, market, market. Communications from the PMO are critical. We’ve always said this to our clients but selling the PMO shouldn’t ever stop once the PMO is established. An organization with lots of responsibility and little authority needs to lobby for its position forever. It’s just part of a good PMO. So, create a blog, a collaborative workspace or a website and start pitching your benefits to the organization straight away.
Next, keep your friends close but your enemies closer. It’s an old expression but it holds true today. Make sure your portfolio selection process or your project prioritization process includes those very department heads who feel they might become disenfranchised. Making sure that people in authority don’t feel left out can eliminate a huge risk to the PMO.
Finally, become Switzerland. Being the facilitator of portfolio meetings puts you one level beyond inter-department rivalry and makes you the neutral territory on which departments can negotiate. Having a neutral territory somewhere which prides itself on its neutrality rather than an organization which is looking for authority of its own is something everyone can commit to.
Maintaining a level of balance between the organizational and project axes of your matrix organization is essential if you don’t want to risk being returned to a silo organization.
I own a company that does deployments of Microsoft’s Enterprise Project Management (EPM) Solution. To be fair, HMS Software does more than that. We’re also an ISV but I spend a fair amount of my time working with mid to large organizations on how they can deploy EPM. Some of the challenges are specific to Microsoft’s technology but many of them are similar to what I’ve seen companies face since I started in the project management software business in 1983. We’ll look at how you can plan your own EPM deployment here.
One of the biggest challenges we face when we start an EPM deployment is establishing a credible roadmap for producing the intended result. While we have done enterprise project management systems deployments here for over 24 years, one thing that hasn’t changed is the desire of senior management to have all the results yesterday.
The challenge is compounded by a couple of factors that are almost always present:
1. Sales has shown the client the end-result without explaining the effort that would be required to reproduce the effects in a production environment or even how much effort went into creating the virtual image and data involved in the sales demonstration (typically several man-months).
2. Microsoft carries an ease-of-deployment legacy. People have gotten used to stuffing a DVD into their PC, waiting until it pops out and then getting the benefits of the software they’ve purchased immediately. Oh, there may be some notion of optional training but there is rarely an expectation that what is being undertaken is an organization-changing exercise.
What is Enterprise Project Management?
That would be challenge enough but there are other aspects that are often overlooked by the client during a purchase starting with ‘What exactly is EPM?’ That’s a short question with a potentially long answer. In the early stages of an EPM deployment we will do an envisioning workshop with the client’s senior management. One slide that I always use looks like this:
“What is EPM from your perspective?” I’ll ask. The responses are often found in one of the circles on the slide. The responses might be:
Basic Project Management
“For us, enterprise project management would mean that everyone would be doing project management the same way and using the same tools.”
Enterprise Project Management
“That wouldn’t be enough for us,” someone might say. “For us, enterprise project management would mean that our project management data would be integrated. We would be able to get reports that would show our schedules in an integrated summarized report and we would be able to manage the impact from one project to another.”
Project Portfolio Management (PPM)
“It’s about project portfolio management for us,” someone might say. “For us, enterprise project management would mean managing one level higher at the project level. We would need to group projects into portfolios, report summarize and analyze them together. We’d need to be able to follow progress at that level as well as implement stage-gating.”
“For us, enterprise project management would mean resource capacity planning. We need to know not only if we can take on a new project and what the impact might be on existing commitments, we also need to know what the status is of managing the work we’ve already committed to based on project progress and resource availability. “
“For us, enterprise project management would occur in the reports,” someone might say. “We need a report that pulls from project management, finance, HR and other internal systems to make roll-up reports for management and decision making. While we’re talking about reports, we’ll also need dynamic dashboards, scorecarding and other visible systems.”
Budgeting and Cost management
“For us, enterprise project management is all about the money. We budget at the beginning of the year. We then budget for each project and the only thing that matters for us is tracking the money against the plan, month after month.”
“Never mind the planning. If you could just tell me what my people actually spend their time on, we’d be so far ahead of where we are now, we’d call that an epm success,” someone often says.
Communication and Collaboration
“It’s not about the fancy algorithms. We need to facilitate talking to our people. Can you help us connect our project teams that now include not just planners but also senior management, clients, users, sub-contractors, outsourcers and team members?”
Integration with External Applications
“We’ve got a big ERP/Finance system which is great except that we don’t have any of the forward looking projections for deliverables and costs that come with project management. If you could connect a project management tool with our ERP/Finance system then that would be plenty of enterprise project management for us!”
“We envisage a system that tracks not just tasks but procedures in an automated fashion. We’d like project managers to fill in an online form to request project funding which would then go to the person responsible who would then, in an automated fashion, accept or reject the request. If approved, the project would instantly be included in the EPM system. We’d like to do the same with all our project documents. In fact, we’d like to automate all our project management procedures in this way through workflow management. That would really be enterprise project management.
“What we need is scorecarding, dashboarding and data mining of our project data,” some people will tell us. That would be the ultimate Enterprise Project Management environment.”
The Project Management Maturity Model
“We’re working on improving our maturity level as measured by the ‘Project Management Maturity Model’.”
So, what’s the right answer? They’re all right. In fact, it’s probably not an exhaustive list. EPM can mean so many things to so many people and is highly dependent on the perspective you are looking at the problem from.
When we do this with senior management, what often happens is that there is no one of these aspects that is not desired. Yes, people want all of them. And, when they ask if all of this is possible in a Microsoft EPM Solution deployment, the honest answer is, “Yes”. The problem is, that each of these aspects of EPM can be considered as a vector or a direction in which you can push the EPM environment. If we decide to push on all of these vectors on the first day, the size of the project we’ll end up designing will be so large, so potentially disruptive, so complex and involve so many other corporate systems that it will have little chance of success.
Remember, an Enterprise Project Management deployment isn’t just technology. If it were, the implementation would be over in a few days. No, an EPM deployment involves Strategy, People, Process and Technology. Successful Microsoft EPM Solution deployments virtually always consider the project a ‘Change Management’ project rather than a technology project. What we’re looking to accomplish is to change the way the business works. How? Well, depending on which direction an envisioning exercise goes, the direction could be very different.
We know though, that making a huge project that’s very difficult to understand all of makes for a highly risky project.
EPM Deployment Approaches
Let’s talk for a moment about how many people approach an EPM deployment. There are a couple of possible scenarios
The Big Bang theory says “Let’s do it all!” The idea is that we’ll spend an inordinate amount of time designing, building, rewriting and programming the ultimate enterprise project management environment. It will take a phalanx of programmers and one day, sometime in the future, on a given weekend, we’ll flip a switch and everyone will have enterprise project management. If we were to graph this as Return on Investment over time, it would look like the picture at right.
There are pluses and minuses to using the Big Bang theory. On the plus side, there’s a better chance that with other types of approaches that the end result will be closer to the original intent. After all, the team doesn’t rest until they’ve checked off all the desires created at the beginning of the project.
On the negative side, however, there are a few big challenges. First of all, the organization doesn’t receive any return on investment until the project is 100% complete. That may be months or a year or more down the road. Every day that the project is incomplete is a day someone can wander through the building with a “better” idea. Also, the nature of life is that it changes. Any team change, management change, change in corporate mission or strategy, change in fundamental technology architecture, change in corporate ownership can result in the project being restructured or cancelled. If this happens, the organization receives nothing for its efforts.
The Instant Bang
When we talk about the legacy of instant gratification legacy that follows Microsoft, we see a different phenomenon. Some clients will assume that deploying the Microsoft EPM Solution is just like playing a Microsoft Game. We load in the DVD and a few moments later, we’re doing projects in a coordinated, collaborative fashion. The return on investment looks good for a few days or even weeks as the pilot group with the most excitement over the new system starts to use it. However, without the investment of the senior executives it is extremely difficult if not impossible to effect culture or behavioral change and the project rarely extends. The system stays in use for a short period of time and then is either abandoned or left in use by a tiny number of users who are often frustrated that they’ve been unable to entice the rest of the organization to work together.
The Phased Approach
Ø First, the organization starts to receive a Return on Investment early in the process. This serves to safeguard the implementation and validates to management their decision to do an EPM deployment in the first place.
Ø Second, the deployment tackles whatever technical challenges in waves rather than all at once. As the complexity of the system grows, so too does the maturity of the organization in handling that complexity.
Ø Third, the deployment eases the culture change into the organization over time which is always easier. It’s a truism that change causes upset. That there will be some upset at such a change in managing projects is a certainty. Deploying the entire vision over time lets the users adapt to the different way of doing business.
Ø Finally, no matter how much time the organization spends in doing the original design, it is bound to change its mind as soon as it sees the system in operation. Getting that first phase of the deployment into production earlier lets the organization learn from it as they move forward.
The most critical element of this plan is the first phase. We instruct our consultants to determine “the most minimal deployment possible which will return an ongoing positive return on investment.” I’ve worded that very carefully. We want to find a first phase of the deployment that can be put into production that will provide results and that each week will give back more benefit than the effort required to produce them. If we do that, the deployment will last forever. No one would remove the deployment because they’ll say, “Oh, we can’t remove that, we get ‘this’ out of it every week.” If we’re successful creating that kind of deployment, we’ll be able to build on it in the months to come. If we’re not, the project and the deployment is still very much at risk.
Getting started with your EPM Deployment strategy
If I’ve made you think twice about doing an EPM deployment, that’s probably a good thing. Not that you should not do it but a successful EPM deployment always starts off with a bit of extra thinking. So, how should you go about doing your deployment? Let’s start with a few prerequisites.
1. The Project Management Office
If your intention is to deploy an enterprise project management environment, there’s no way around having an enterprise project management organization. This is commonly referred to a Project Management Office or PMO. You can call it whatever you want, but there’s got to be a central management of a system like the Microsoft EPM Solution. Who will declare templates to be the ‘official’ template? Who will determine who has authority to change resource priorities? Who will determine what a report will look like and who will have access to it? Who will decide whether to manage risks and if so, what process must surround it? And so on, and so on… No, a PMO is essential. If you don’t have such an organization (even if it’s one person) then you’ll need to start there as one of the earliest steps towards your EPM environment.
2. Executive Sponsorship
Next, get sponsorship and support from senior management. Whoever is supporting this project from the executive suite needs to know not only what the goals of the deployment are, but how long they’ll be required to provide support. We typically tell executives to plan for a minimum of a full year of sponsorship duties. One pitfall that we often see is a small group of middle management or project managers who desire an Enterprise Project Management environment but lack executive level support and decide that they’ll try to do the deployment themselves in order to get that support. It’s the Field of Dreams “Build it and they will come” approach and it’s almost never successful. The problem is, the very benefits that would be attractive to management (such as pm methodology compliance, global project reporting, resource capacity planning, and collaborative project management) are those benefits that can only be achieved with the participation of management.
3. We’re project managers – we don’t need project management!
If you want to avoid the most common pitfall to an EPM deployment, make a project plan. I know, that sounds strangely simple but it’s amazing how many EPM deployment projects don’t, in fact, have a project plan. One of the easiest pieces of advice we can give to organizations considering deploying the Microsoft EPM Solution is to make it a project and to apply all the same methodology they already use for any other project. Is there a project schedule; a budget; an executive sponsor; a project charter; resources; success metrics? These things might be found in every other project in the organization but, just like the shoemaker’s children who go barefoot, project managers often forget to apply their skills to their own projects.
4. Set goals
Work at the very beginning of the project to determine what the measures for success will be at each phase. Have a clear set of performance metrics goes a long way to helping not only the project team but also management focus on completing a phase of the project.
If you’re wondering how to get started, here are a few suggestions.
Start with a facilitated vision session with senior management. If you use external assistance in no other aspect of the project, you’ll find it’s most useful here. Having someone who has been involved in several other EPM deployments is key to success. We’re not just talking about someone who has been a user of an EPM system but someone who has worked through some of the issues we’ve described above and who has a good understanding of both the capabilities of the Microsoft EPM Solution and the process of managing projects in an organization.
One of the things you’ll need to decide on early is who is the ‘enterprise’. I’ve used that term several times in this article but the enterprise could mean whatever you decide. Is it your department, your division, your entire company? One common mistake made by people doing a deployment is making a plan for an entire company but only having authority over their own division. The hope is that others will come on board if the system is available. It’s a variant on the Field of Dreams approach and it makes for a solution that’s not attractive to those other divisions and not useful for the ones who you do have authority over. So, decide early who will be involved and make sure they’re included in the planning.
Make a Project Plan
Just like you would do with any other project, take the time to make a proper project plan. There are numerous plans available online that will give you guidelines on some of the subjects that you need to cover. They’re a good place to start but you almost certainly have all the skills required to make a proper project plan for an EPM deployment.
If you are considering or have started a deployment of the Microsoft EPM Solution, focus your deployment by considering these three points:
1. Treat this project as a project. Use all the skills you already have for managing projects to manage the Microsoft EPM Deployment project. Remember, it’s primarily a change management project not a technology project.
2. Break the project into manageable pieces and treat each phase of the project as a sub-project with its own success metrics, schedule, budget and resources. You’ll get some of the benefits of the overall system faster and that will serve to get even more support from management.
3. Remember that Return on Investment has to work at every level. It’s not enough to make a system that works for senior management but doesn’t work for the people who have to manage it. Or, a system that works for the project managers but doesn’t deliver the reporting required by senior management. Or, a system that works for the project managers and senior management but is too hard or too much effort for individual users. Each person who must invest time and energy into the use of the system should be considered in terms of their own return on investment.
If you’re designing a deployment that follows a phased approach and uses the basic project management methodology you already have for other projects, you’ve got a great chance of success. Good luck and happy planning!
Gantthead – www.projectmanagement.com
Gantthead burst onto the project management scene over 10 years ago. They are now known as ProjectManagement.com and are associated to PMI. Their model was to be a center of excellence for project management information, and they’ve done a fine job. There are thousands of project managers who visit the site on a regular basis. One of the draws on the site is the remarkable number of articles, processes, downloads and other free information. Just sign up for a free login and you’ve got instant access to tons of information.
Microsoft Office Online Templates – office.microsoft.com/en-us/templates
If you’ve got any recent Microsoft Office Product, then clicking Help will bring you information from Office Online. This is an area of Microsoft’s website that carries templates for all sorts of products. Don’t choose the product first – just do a search on Project Management or just Project and you’ll find templates for MS Project, but also for Visio, Excel, PowerPoint, Access and even Word.
US Small Business Administration – www.sba.gov
The US Small Business Administration gives away a ton of information to those interested in creating a small business. A lot of this information is of use to anyone doing project management. It’s worth browsing around for 10 minutes to see if the online courses, templates for business plans, or articles are of any interest.
ITeamwork – www.iteamwork.com
This free use site allows you to use the web-based system for creating a list of tasks, assignments and notes and seeing your tasks online. It’s best for smaller projects where you can work online.
AceProject – www.aceproject.com
Here’s another interesting hosted system. It’s free for up to five users and five projects. Users can then log into the hosted site to see their assignments. You can schedule tasks, assignments, manage inter-project workload and more. If you’re a small team – it’s a tough deal to beat.
TaskJuggler – www.taskjuggler.org
More free scheduling and resource management software. This one is a Linux/Unix product available for downloading and use by a project manager who wants to see a Gantt and other key information about their project. It’s an Open Source product.
Project Workbench – www.openworkbench.org
This product is a free open-source download of the old Project Manager Workbench by ABT. ABT was bought by Niku, and Niku is now part of Computer Associates but the product still has depth and a strong set of tools for scheduling projects, grouping them into portfolios and assigning resources. Workbench was popular among the IT scheduling crowd. The publishers decided to make this product open-source and freely available for download years ago while they concentrate more on their enterprise project business.
Google Documentation – www.docs.google.com
How can you beat this? The free Google Docs service lets you upload files or create them on the fly. Since you can share docs with others in your network, you can create an easy to access site for document collaboration almost instantly.
Bluetie – www.bluetie.com
Got a project team and need an online home to collaborate? Check out Bluetie. You can become your own “Enterprise Manager” for free and add your project team right online with their own user logins. Then add tasks, contacts, calendar events and documents, and then see your to-do list along with how your team is interacting. You can upgrade to the commercial service if you need more people or capacity. If you’re keen to create your own collaboration environment, then take a look at SourceForge (below) there are numerous Windows and Linus Collaboration portal tools available for free download. Just search for “Collaboration” “Portal” on the SourceForge site.
SourceForge – www.sourceforge.net
There’s too much to list here. SourceForge is a huge repository of open-source products. Some are available for Windows, some for Linux, some for Mac and some for multiple platforms. You’ll find everything from web-based project offices to collaboration tools. Do a search on “Project Management” for literally hundreds of possible downloads.
There are many free tools and services but it’s worthwhile thinking for a moment or two before you jump on board with one or more of them. First of all, just because software is free to download doesn’t mean that the TCO (Total Cost of Ownership) will be less than if you purchased a product from your regular supplier. Here are a few things to think about:
How will you get support for this product? Will you have to hire someone who is an expert in that programming language or that software platform in order to be sure that you get the service you need? In some cases, you might find an open source product but not on your most commonly used platform. We have seen products in our office, for example, that would work only in Linux and the total cost for us in using them would have had to include adding personnel, or training personnel in skills that are not part of our core competency. With an Open Source product, will you have to do your own technical support? There’s no one to complain to if a calculation is wrong. If this is for a small personally run team, then perhaps the impact of such problems are minimal – but you need to think about this carefully in a corporate context.
If you’re downloading “Free” software the license agreement is something that you might want to take a few minutes with. For example, some license agreements put responsibility on the end-users who use the software. These obligations might include posting any changes that you do to the product and not embedding the product into something you resell without offering royalties to the original publisher. Again, for the individual this isn’t likely to be a concern but in a corporate context you need to take a moment to be sure this is what you want.
Sometimes we’ll start on a product or hosted service with the notion that it looks just right for our team. But what happens if you expect down the road to move this information to a corporate system? Will you be able to extract the data in the format you need and migrate it somewhere, or will you be caught re-creating that data when you eventually migrate?
With a free hosted service how canl you be sure your data is properly backed up? Given what you’re paying (nothing!) there’s not a lot of leverage to complain when your project plan or your bid documents go missing. Check with the service to find out how you can be sure your data is safe.
Free Hosted Plans
With all the free-hosted plans, the service agreements state that there’s no guarantee the service will continue to be free or, in fact, continue at all. So, what is your contingency plan if the service evaporates overnight? Do you keep off-site backups? Can you recover your data if need be?
In the end, Heinlein has a point: There Ain’t No Such Thing as a Free Lunch. Still, some of these free products and services have some great capabilities and functionality and are worth keeping track of. The “Free” hosted services are almost always attached to paid-for services that are also extremely interesting. Go into these products and services with your eyes open and you might just find a gift horse.
The idea of having software as a series of interrelated parts that could be made into plug-and-play components of a larger system often meant we would need to do lots and lots of programming of the interrelating software. Our company has focused on solution selling for years, so for us we’re used to asking a client for the problem before we list the solution. But it does make us think around here of software more as a vehicle for creating a solution, rather than a list of features that the client might find attractive.
In the last couple of years, however, there has been sufficient movement in the software business towards more common standards that we can start to think of technology as a “stack” of functionality, and interact with it as the potential for a solution, rather than the fixed list of what can be delivered on the first day.
I recently presented some project management software to a rather large company with a worldwide brand name. This company certainly has extensive project management experience but in the particular division I was interacting with, project management had always been an ad-hoc or project-by-project notion rather than centrally organized. The division’s volume of work has recently increased, however, and the complexity of that work has grown by an order of magnitude. It’s time to make project management a more formal process.
So, I showed them this software, which was rather well received. I showed the software as I often do, after extensive conversations about what the company is attempting to accomplish. Once I’d done the presentation, I turned off the projector and told a story.
“Imagine,” I said, “having to create a new project. You wouldn’t turn on the software we’d just shown you. Instead, you’d click on a link on your corporate intranet portal. The link would present a web-based form for new projects. You’d fill in this form on your terminal. You wouldn’t need specialized project management experience. You might not need to know how to create the schedule and establish the dependencies between tasks, or what a lag is, or that CPM stands for Critical Path Methodology. You’d just fill in this form.
”Depending on who you are, the form might look different. If you were a senior executive for example, certain parts of the form for approvals might not appear. Other parts of the form might only appear depending on other data you’d enter. If the project details you entered had, for example, a place for the cost of the project and that value was, say, more than $100,000 then another part of the form might instantly appear with additional fields of information required to start a project of that value.
“Now, imagine once completing that form that you click on the ‘Submit’ button and depending on who you are, and the data in the form, it is automatically sent to the person in your organization who needs to approve new projects. That person would receive an email in their Inbox. They might see the whole form there or click on a link to the form online in their browser. They would see what you had typed in but they might also see other information. Perhaps they can see right on the form, for example, the value of the project you typed but also the total value of the budget that has been allocated so far for this year. They would see different buttons on the form such as ‘Reject’ or ‘Request more details’ or ‘Approve’ or ‘Forward for approval’. They would click on the ‘Approve’ button and several things would happen. First you would get an email saying that the project is now approved. In your Enterprise Project Management system a new project would instantly appear. It would have the data from the form that you filled out. There might even be a very high level schedule of milestones if those were required in the form for new projects. The stage for the stage-gate methodology would be set to “initialized”. Other key people might be triggered by that event to create certain project documents and so on and so on.
“Now we can do the same thing with change management, budget approval, resource allocation etc.”
There was nothing on the projector. It was a story. But the story was compelling.
“That’s just what we need,” said the representative of the organization.
All of this has become possible and not just with one tool. In fact, if you wanted to make my story into a solution, there are several tools you’d go to look for. They might come from the same vendor or from several vendors.
You’ll need a server-based enterprise project management system of course. That’s a good starting point and there are a number on the market.
You’ll also need server-based workflow engine. Again, there are several on the market that are quite excellent and can be configured without having to be a programmer.
You’ll need a forms-generator for online forms to be able to create intelligent forms that can take actions in the background. Most workflow vendors have such forms-based tools embedded in them or attached to them, but most workflow tools can work with numerous forms tools.
This interoperability is all thanks to the ubiquitous presence of the Internet and the movement from older client-based systems to server-based centralized systems. This has prompted more and more vendors to open their technology. We hear more of the terms “Software as a Service” (SaaS) or “Simple Object Access Protocol” (SOAP). The movement towards Software available as a Service means that whatever functionality is available can be used by different interfaces to create blended functionality. The standard of SOAP and other such protocols means that everyone has a standard syntax and grammar for communicating between products. The end result is the potential to combine the functionality from where you can find it into the solution where you need it, and that’s all possible today.
That’s all the good news.
I know. You were waiting for the bad news weren’t you?
The challenge is what’s implied in my story. The workflow sounded wonderful to my client but, if I want to implement that technology, we need to know what the workflow is. That implies a standardization of process that everyone in the organization agrees to. As I’d mentioned earlier, this particular organization had managed projects in a very casual ad-hoc manner. So getting consensus on what the new project process might be will almost certainly take some work, and consensus is key. Also, we can, in theory, proceduralize almost anything, but the law of diminishing returns takes effect in here somewhere. There will come a point where making a formal automated process of one more procedure rather than leaving it to be managed casually won’t produce any more efficiency. There needs to be someone central to make the decision on what that point is.
Who will make the final decision on what to proceduralize? Who will have the final say on what a particular process will be? What will be the process to change or add to the process? If the processes we’re discussing will touch several departments (such as Finance, or HR) instead of just project management, then who will be the liaison for those departments? Who will be the keeper of the process? What is their authority in the organization?
This is why, when I talk about enterprise project management and what’s possible, I inevitably talk about it as a change management project rather than as a technology project. At its core, we’re asking the organization to change how it works and possibly how some core aspects of how it works. That change is always going to be a bigger challenge than the technology required to deliver the solution.
What’s important to know? That it’s now possible to blend these technologies together and as a result bring the project management process to levels of the organization that will never see or need to understand a GANTT chart or a PERT diagram.