Microsoft has published another article of mine on its TechNet site. “How To Cancel a Project Without Cancelling your Career” talks about the challenges we’ve seen with organizations who try to deploy Project Portfolio Management or Stage Gating.  If you can’t slow down, pause or cancel a project then the value of Stage Gating becomes quite questionable.  The article will be of interest to project and portfolio managers of course and those who are managing a Project Management Office but will also be of interest to timesheet managers and TimeControl Administrators as the data from how a project is actually progressing often comes from a project oriented timesheet system.

For many in the project management industry, the idea of cancelling a project is extremely difficult in part because the nature of Project Managers attracts personalities that don’t give up easily.  So finding out that there can be a positive impact on the organization by cancelling a project can be welcome news.

You can find the article on the Project Server 2010 0r Project Server 2013 pages of TechNet in the “From the Trenches” column or go to it directly at www.microsoft.com/en-us/download/details.aspx?id=36430. I hope you enjoy it.

We spend a lot of energy in project management circles trying to determine how to do a thing. In my travels to various parts of the planet something that’s sadly lacking in many places is good judgement on whether we should do that thing.

I’ve told the story before of an engineering organization that was looking for a new timesheet system. This sounded like good news to me because our own TimeControl timesheet system is a good fit for engineering firms. Yet, I was less happy when I heard the reason why the customer felt that their existing system was no longer able to meet their requirements.

“We’re having to do a whole manual transfer of data from that old system to our Finance ERP,” explained the technology specialist. Because they need 3 rate values and our existing timesheet can send only two we’re having a miserable time with all this manual intervention trying to get a third value stored and sent. Can you that with your TimeControl?”

TimeControl was certainly capable of sending multiple rate values, I assured the specialist but I was at a loss to understand why they needed such an interface in the first place. In the end, after some discussion, the client agreed to pay for a day of system design and I scheduled some time in the offices.

Our meeting together started off just great. They had the CIO in the room and I was suitably impressed that the head of the IT department was sufficiently interested in the problem to attend himself. He and the technology specialist took turns white boarding the problem By our mid-morning coffee break we had a combination of boxes, diamonds, circles and lines in the four basic white board marker colors all over the board.

I took copious notes.

By the break though I had my first intelligent question. “What was the volume of transactions,” I asked, “that was being handled through this manual process?”

No one knew the answer.

“Can we ask the CFO?” I asked.

A quick call was made. Yes, the CFO was keen to talk to me but could only do so over lunch. I was delighted. Senior management intervention at such a rapid pace isn’t that common and indicated to me that management was committed to get this problem handled. Things were looking good.

We worked for another hour on the white board diagram. I headed to lunch with the CFO, the CIO, and the technology specialist that had called me originally with a good understanding of what they wanted and the kind of time it was going to take to create. The CIO and I agreed that changing the timesheet was fundamental to the new solution and that 6-8 weeks of developer time to automate this “archaic manual transfer process” sounded quite reasonable. I was upbeat. Sounded like some business on the way.

Yet, there was something niggling at the back of my mind. The whole premise of the problem came back to a lack of a single field in the old system and its inability to move that column of data to the Finance system. I’d already determined that this data was critical to the corporate effort “Why not just give up on that extra data,” I’d asked. “What would happen if you just didn’t transfer the data?” The CIO had told me he’d already considered just that and that management had made a good case for this data being essential to their ability to bill accurately.

Time for lunch. We went across the street for chicken. (Business lunches always seem to be feather, leather or fish!)

I sat across from the CIO with the CFO to my left. The technology specialist was across from him. We exchanged pleasantries and then ordered and while we waited for our meal, I turned to business.

“I’m here to work on this timesheet system to finance system interface,” I explained. “The CIO here and your technology specialist have been describing the challenge but perhaps you could describe your understanding of it in your own words.”

The CFO to his credit describes exactly what we’d been talking about all morning. This was a good sign. Often when you go back to the client or end user of a system, the understanding of the requested change isn’t at all what IT understands.

“Now could you describe how you handle the interface now,” I ask.

“It’s an archaic manual intervention,” he describes. Again, sounds just like what I’d heard this morning.

“And how many transactions are managed through this archaic manual intervention?” I ask.

“Oh about 5 a month,” he says.

There’s silence at the table.

“Five,” I repeat. I see the CIO’s jaw drop out of the corner of my eye.

“Yes,” says the CFO.

“And how long does it take to do these transactions manually each month?” I ask.

“Oh, it takes one of my staff about 20 minutes,” he says.

“Excellent,” I say, my heart sinking as I changed the subject.

The CIO couldn’t meet my eyes. We finished our meal and headed back to the office as we did so, he walked next to me. “I’m so sorry for wasting your time,” he apologized.

“No need to apologize,” I said. “I’m just happy we figured this out before spending 8 weeks on writing the interface.”

The time to recoup a return on investment from the effort we’d described would have been many years. At 20 minutes a month there was no point in doing the work. In fact, the company had already spent way too much time working on how to do it already.

Could we do the work? Sure. But we shouldn’t.

And sometimes that is the most effective project of all.

“But the timesheet will update the project scheduling system in real-time, right?” says the project manager.

It’s a question I’ve heard many times before. It’s not that unusual for me but then, I have a company that publishes timesheet software for the project industry so perhaps I hear it more than others. The question isn’t at all uncommon for me but it’s also a question I dread hearing because the answer is inevitably much longer than the question and is rarely what the questioner wanted to hear. The notion of “real-time” project management has been around a very long time. Many publishers in the project software industry have used the term to entice clients who dream of “one-button” project management and “instant-feedback”. Before we can even start to answer the question posed to me, we need to look at what Real-time project management is and its implications:

First of all, what is Real-Time project management?

The expectation of some managers is that as individual project resources complete their tasks or report on progress as the day advances, they will be able to see the sum total of all projects progressing. Individual project managers might envisage little red bars turning green as tasks get completed throughout the day.

Is this even possible?

Sure. Modern day systems can move data as fast as you like. It’s not complicated to have a task updated by a user somewhere in the organization flag an update in the summary of the project. In fact, some vendors go out of their way to make this possible. It makes for a lovely demonstration of these “real-time” capabilities which is, after all, what those managers are hoping for.

Sounds good so far – Is there a problem?

The problem comes in terms of the assumptions we make when we look at project data. When we look at a GANTT chart or report of any kind in a project schedule, we have a few basic assumptions. It’s not obvious but think about what you take for granted in the data you’re looking at:

1.  
    
2. You assume that the data is complete

   Particularly when we look at a task’s schedule or at the task’s resource information, we assume that all information that relates to that task has also been updated. In a project schedule, almost everything is related to everything else. Missing even one task’s update information or one project resource’s update information may mean that the schedule you’re looking at is completely inaccurate. So, is the data all here? In particular when we talk about timesheet data (as that question to me was) finding out if we have all the timesheet information is essential. Did everyone submit their timesheet? Were they all approved? Are there any timesheets still outstanding or still stuck in the approval process? It’s no surprise that one of the most popular feature of our TimeControl timesheet system is the “Missing Timesheet Report” and “Missing Timesheet Email notification”. Getting 100% of the data collected can be a big challenge.

3. You assume that the data has been approved

   When a manager looks at project data, they have a natural assumption that the information they’re looking at has been approved by someone. Senior management won’t expect that they need to go to every individual project resource to determine that the schedule information is accurate. They expect that they can go to the project manager and have that project manager stand behind the data. Project system information is, after all, a synthesis of a lot of individual pieces of data that is analyzed and then presented in a particular way. Senior management assumes that the data that they’re looking at in their dashboard or in that management report has gone through some kind of approval process. This is particularly interesting as when we point out to management that they desire instant real-time feedback but also expect that the data has been approved in advance, that the two desires conflict.

4. You assume that inter-related data has been updated as well

   This is an easy one to miss. There are numerous potential elements of related project data but here are a couple of examples. If there are interrelated project schedules where the task of one project can push the schedule of another, we assume that this has been updated too when we look at our schedule. Or, if we’re looking at a related risk management table, we assume that it is up to date when we reference it from the schedule.

All of these assumptions carry implications. It’s certainly possible to create an automated project system that identifies when data is incomplete and show that on a dashboard or on a project report. But, in the excitement of imagining our soon-to-be real-time project system, it’s easy to overlook what we’d need to do in order to make use of the concept.

First, we’d need to be able to ensure that all data was collected hour by hour so that data was complete all the time. This is a herculean job. Anyone who has collected timesheets each week and ensured they’ve all been collected can attest to how much work it can be. Now imagine that you’re going to do that work twice a day to get project updates every 4 hours. It may well be impossible. If you don’t have 100% of the updates, are you prepared to use the resulting project data knowing that it may be incomplete? Perhaps the 20% of task updates you’re missing represent 80% of the schedule delays.

Next we’d need to be able to ensure that data was all reviewed and approved. Again, this can take an extended effort by the project manager or project scheduler each week. To do approvals like this twice a day could easily take longer than a half-day to accomplish for some projects. In environments where project schedule data must be updated shift-by-shift such as in a short-term shut-down/turn-around schedule, such efforts are done full time by a dedicated team of staff. The results are entered in the next shift for viewing a shift later. In almost any other environment, the organization won’t find the effort to update that frequently provides enough return on the investment to make it worthwhile.

When I’m approached by management and asked if I can provide real-time project management dashboards or real-time project management reports or, when I’m asked “But the timesheet will update the project scheduling system in real-time, right?” I ask a couple of questions in return:

“If I give it to you, what will you do with it? Are you ready to do real-time project management?” By that I mean, “Are you ready to take action all throughout the day as data would be presented to you?”

And, “Are you ready to put in all the effort it will require to collect, validate that it’s complete and approve the data before you look at it?”

When most people think about it, they put the idea of real-time project management onto the backburner… for now.

People are always coming to me asking for my help designing a solution they’ve already designed. It’s not their fault of course. Project Management software vendors have become very adept at creating marketing materials that make it look easy to deploy an enterprise project management solution “out-of-the-box” so if you find some solution for a particular problem in the marketing literature, it seems an easy decision to make.

Take an example I had recently. A project manager in an service business called asking if I could help deploy a server-based EPM system. I started to ask the questions I always ask: “What kind of projects are they? How do you manage these projects now? How big are your projects, how many do you have? How many people are resources in the system, how many people would be users?” only to have the person stop me in mid-stream to tell me that the answers to these questions weren’t important. They’d “already chosen the solution,” he told me and just needed someone to make it work.

I explained that I was in the solution business and if I couldn’t understand the problem, I wasn’t the person to deploy the solution. We talked a little longer and the problem the client kept describing was that they had outgrown the scheduling they’ve been doing manually using Outlook calendars and now needed to “upgrade”.

It’s not the first time I’ve been confronted with this exact request. Could we migrate a manually-driven Outlook-calendar resource scheduling system to an “automatic” Microsoft Project Server system? The answer to this is almost always no. This answer shocks and upsets everyone who gets it. “But there’s an Outlook module/connector in Project Server,” they explain to me patiently. Perhaps if I’d only known this I’d see the light and deploy what they want. They seem more upset when they find out that I’m aware of the Outlook connector and other Outlook tools.

The challenge in these situations isn’t the technology involved. This person was quite right. Microsoft has a new Outlook connector as part of Project Server 2010 that links to Microsoft Exchange Server. There have also been Outlook connectors in earlier versions of Project Server. The problem this person has is that he wants to move a relatively small organization which has allocated resources to tasks more or less manually with a single person or a person per large department sliding tasks manually into calendars into an organization where project scheduling, centralized resource capacity planning, resource conflict resolution and an enterprise project management process and associated tools are all automated to the point that the work happens automatically.

That’s a corporate culture and process change, not a technology change. I understand how tempting it seems when the solution for all the organization’s challenges seems only a software purchase away, but software is better considered as the potential for a solution rather than a problem-solved. Getting the software to the point where the problem that was originally encountered goes away may take a lot more thinking as well as resources, time and money. In the end, sometimes going with the large EPM deployment makes perfect sense and other times not.

Let’s take the original problem encountered by the organization who called me. What is the problem exactly? When we dig a little deeper, it seems that the problem is that the challenge with scheduling manually is when work occurs out of sequence or is delayed. When that is the case, then connected tasks such as we’d naturally think of in a logic-driven schedule don’t automatically move. Ok, anyone who’s done a basic course in project management and critical path theory can get that. Then, when we look a little deeper, it turns out that several division leaders are trying to share these Outlook calendars at the same time and doing so means that they can’t determine the priorities of different projects.

Well, if we could centralize scheduling into an actual project schedule, we might do well with having a small project office with one or two co-located schedulers.

But presenting that to the organization immediately generates resistance. What now surfaces is that the client loves how Outlook presents the tasks to the users and how users get these tasks by email even when they’re changed on short notice. This is why they went to looking at the big centralized enterprise project management system in the first place.

If we just take the problem though then there are lots of ways to build a solution: First of all, if we stay in a strictly Microsoft world, Project Professional 2010 can read and write the tasks from a SharePoint list. Outlook users can subscribe to such lists and even get email notifications when the list changes.

Next, if we just look at using a copy or two of MS Project centrally, we can use a tool like Housatonic (www.projectviewercentral.com), EasyTaskSync (www.easytasksync.com) or EasyTaskLink (www.easylinkmail.com) to move data back and forth between Project desktop and Outlook.

Lest we keep the whole conversation Microsoft-based, similar tools exist for Oracle-Primavera. PRMLook (www.primaveratools.com) for example links a Primavera schedule with Outlook.

If we look outside the box some more, TrackerOffice is a project management tool built around Exchange.

I’m not advocating any of these solutions but my point is that there are a lot of paths to get to a solution that may be appropriate and the best selection is going to have more to do with the exact nature of the enterprise and the challenge they’re facing than it is with the brochure of whatever software is being most heavily promoted on a given day.

“Work the problem, not the solution” we tell our consultants. It keeps us focused what ultimately makes a difference.

Over the last 5 years I’ve spent a fair amount of time working with Microsoft on deployments of its Project Server system. Microsoft refers to its entire solution as the Microsoft EPM (Enterprise Project Management) Solution as it encompasses much more than just Project Server. To consider the total solution we think of a “stack” of technology. There is Microsoft Windows Server 2003 to start with. Part of Windows Server that’s critical to this kind of deployment is Internet Information Services which is the Web Server for delivering all the web content. Along with Windows Server is Windows Sharepoint Services (This is included with Windows Server) which provides us with collaboration and web portal functionality. We often do authentication with Active Directory so that’s part of the solution too. There’s also SQL Server where we’ll house the database. Microsoft Office Project Professional and Project Server and the Project Web Access interface are the more commonly expected pieces of software. Finally, there are some elements of the functionality that might require Microsoft Office, Microsoft Office System, SQL Reporting Services or SQL OLAP Services.

Quite a mouthful, isn’t it?

There’s no doubt that the end result is a powerful one and no doubt that the solution has been well received. Even among Microsoft’s detractors, there is widespread opinion that Microsoft is a force to be reckoned with in the EPM space. The initial targets for this new enterprise functionality was, to no one’s surprise, Microsoft’s enterprise accounts. Microsoft doesn’t publish numbers of how many such accounts exist but it is no secret that these accounts typically number in the thousands of PCs. In these kinds of companies, there are numerous resources that are applied to an EPM deployment. The IT department has network administrators and installers and technical support personnel. There are database Admins and programmers and so on. Well it’s been 5 years now and Microsoft has surely had the chance to present their solution to all of their enterprise accounts by now.

I bring up this whole topic because what Microsoft is about to confront is surely a trend to be considered by everyone who creates systems for enterprise project and portfolio management. Microsoft must, over the coming years start to look beyond just their enterprise accounts and see how they can craft a solution and a sales and deployment message that is as attractive to the mid-market as the one for the enterprise market was.

In our business we get calls almost every day from a mid-market sized firm. “How long will it take us to implement Project Server,” they ask. The question is worded in different ways but it becomes clear quite quickly that an answer that is in the denomination of months isn’t going to find any traction. I can’t tell you how many times we’ve gotten a call on this subject that sounds like, “Can you get the whole job done by Friday?”

With enterprise level clients, there is almost always an understanding that the deployment of such systems must be managed as a change management project. It’s the culture change, not the technology which is the big challenge. This is no surprise in a large firm. We’re talking about managing a major aspect of the business in a different way and this may well have a ripple effect through the organization.

There are aspects of this that are true at the mid-market also but it’s a truism to say that the smaller the organization, the more maneuverable it is. So when we explain how challenging changing behaviour may be, this is often met with more resistance at the mid-market or small-market level.

If you were Microsoft, or another project management software vendor, you’d have to think about how to tackle this market. The same sales model that worked for the enterprise isn’t going to fly here. What will be required is what people always expected from Microsoft: instant results.

This leads to what I believe will be a major trend in project management tools and their manufacturers over the next 5 years: The commoditizing of epm software. Publishers must ask themselves, “How can we provide a solution that enables the correct process, is a minimal drain on management to design and configure and is priced in a way that mid-market companies can afford the total cost of ownership.”

So, how do you go about commoditizing such a product/service offering? I have a few ideas.

First, make the technology all install at once
This is within the technical grasp of the large EPM system publishers. Make a one-click install that works for most mid-market size deployments. When we think of an enterprise deployment, we start talking about multiple servers, web farms, load balancing and other high-end challenges that just don’t exist when the total number of users is 200-300.

Next, pre-configure the software for my use
Sure it’s true that every company is a little different but there are many commonalities between firms. Instead of having the software arrive with nothing in it, the publishers could spend time making sure it’s pre-configured for the most common use with reports, customized fields, lookup values etc. all pre-set. Just add users and you’re there!

Also, make training available to the masses
There are so many great ways to distribute training now that EPM publishers need to take advantage of. Online instructor led or Computer-based courses, Teach yourself books, mixes of online and text-books and so on. The costs of such training would need to drop dramatically and the training would have to be broken into bite-sized pieces so any sized organization could digest them.

Don’t forget to abandon acronyms
Any arcane science has its secret codes. In the project management world we talk about things like CPM, SPI, CPI, EV, BCWS and so on. Even in high-end project management circles, these acronyms and abbreviations are being abandoned in favor of straight descriptive language.

Finally, build the processes into the software

There is a process to being effective with managing projects but the 80/20 rule has always applied here. Twenty percent of the process delivers eighty percent of the value. A basic fundamental process, created, perhaps around the tenets of the PMI could be woven right into the software of most EPM systems so that organizations could adopt it or not as they saw fit.

If you think of the project management systems market as though it was a pyramid, with the most experienced users at the top and the neophytes at the bottom, then the use of project management so far has been focused at the very tip of the pyramid. I hear sometimes someone say that all kinds of complex algorithmic functionality should be added to project management software in order to do better analysis but it’s certain that there’s little return for such an investment. No, the big returns for systems publishers are to make project management systems and project management methodology accessible to the masses. It should be like acquiring any other commodity; a bar of soap or a tube of toothpaste. Project management software as a commodity would be used by millions, upon millions of users and that’s where the big payoffs come for software firms.

That makes commoditizing epm software inevitable.

Everything old it seems is new again. One of the earliest programmatic approaches to project scheduling was invented in the heyday of the Cold War. Propelled by inter service rivalries on one side and by the threat of Soviets in the arms race on the other, PERT was born. The Program Evaluation & Review Technique looked beyond a simple Critical Path Methodology (CPM) analysis to introduce the notion of risk into the project schedule. The method was tremendously successful. It was used on the Polaris missile project in the late 50s and early 60s and was credited with enabling the first test launch only 18 months after the start of the project.

The PERT method asks the scheduler to provide three data points for each activity rather than one. Each activity has a best-guess duration but also an optimistic and pessimistic duration as well. The idea is to start by doing the schedule based on only the optimistic, then only the best guess and then finally only the pessimistic durations. As the project progresses and actuals replace the optimistic, best guess and pessimistic durations, the range of risk at project completion decreases.

Why should this matter? Well, if you’re looking at the schedule for any significant-sized project and the result of that schedule says something like “We’ll be done with this project in 2 years, 3 months 6 days and 4 hours, everyone knows that’s a lie. The more likely scenario is that you will be able to estimate within a couple of months yet that’s not how we talk about the schedule. It we had followed the PERT method, we’d have gotten the easiest schedule range from just adding up the optimistic, pessimistic and best guess durations to be able to add “Our most optimistic projection is 2 years and 12 days and our most pessimistic projection is 3 years, 6 months and 4 days”

A range like that may not be what management wants to hear. We know what the reaction from management is likely to be: “You will finish the schedule then based on the most optimistic projection!” But, if you introduce this kind of analysis into every schedule, then you reveal several things straight away. First of all, is the scheduler an optimist (like the one above) or a pessimist? This isn’t trivial. It’s a terribly important thing to know. Also important is the increased credibility of giving a range of dates. It says to the reader that you’ve considered things that could happen to this project (both good and bad) and have given your best possible answer.

For those who spend time in such an analysis, it is also interesting to keep track of the progression of the range. Think about it like this. The day before the last day of the project, the range of possible finish dates is probably very narrow. “We’ll finish tomorrow or maybe the next day,” you might say. On the first day of the project, you would expect the widest range because we have the most number of tasks, which still have optimistic and pessimistic numbers that we’re considering. It’s logical then to expect that the two endpoints (the optimistic and pessimistic) will migrate towards each other as the project progresses. That indicates a healthy advance.

If the endpoints start to move apart during the project, this indicates that we’ve introduced an element of risk into the project that wasn’t there when we started. The endpoints can only move apart when we either add tasks or re-assess the optimistic and pessimistic durations of the remaining work. That’s an easy-to-watch-for warning sign for management that should spark some kind of project review.

We seem to have come a long way since the Polaris missile project but, while PERT did find its fans, it never took off the way that we talk about CPM analysis. Only those esoteric schedulers in the Risk Analysis industry seemed to take any notice and they were working on other things. If you’re interested in schedule and budget risk then you’re probably talking more about statistics that come out of a Monte Carlo analysis, or something much more involved. (“What’s Monte Carlo analysis?” you ask. That’s a subject for another day but suffice to say that the result of such analyses are S-Curves, Bell Curves and probability statistics.)

We still see PERT analysis available in a wide range of project scheduling tools. Some vendors probably wonder why they’re still supporting something that hasn’t got a huge following.

PERT suffered in its popularity not because it was a bad technique (I think it’s a great technique) but because it takes more work. Remember, we’re talking about adding additional elements of data for every single task during the planning process. In some organizations it’s hard enough to get a single data point, never mind three. So given there was more work and no incentive for most project managers to implement the technique, it gradually fell from favour.

So? It’s ancient history right?

Wrong.

While enjoying a quick four-day visit to Sydney, Australia (I’m kidding of course, while I do love Australia, it’s impossible to fly the 26 hours there and the 26 hours back and enjoy only four days in between), I got to meet with and listen to some of the top project managers in the Defence Industry. I took great interest in the sessions on Risk Management, as it’s something I know something about and it’s not often talked about in those terms.

In Australia, defence projects (and other major capital projects) must comply with the AS4360 standard. This standard was first introduced down under in 1995 and thanks in part, I think, to a red-hot economy and a government committed to expanding its defence spending, the AS4360 standard took hold in a big way and has become a staple of large projects there. That might have been the end of this story except that the standard has done so well that there  has been a resurgence of interest in project risk management in the US for major capital projects. Those in the know say that the AS4360 promotes a “risk analysis lite” culture that is quite acceptable to the Defence, Aerospace and Energy projects that should be implementing such techniques.

In particular, one of the components of this newfound interest in risk management is the notion of three-point estimates for schedules, and that is PERT.

If you’ve never done PERT analysis before, it’s almost certainly available to you.  Try it with any copy of Microsoft Project up until version 2007. (The functionality is unfortunately no longer available in Project as of 2010)  Right click on your menu bar to reveal the PERT toolbar. It will show you how to enter your optimistic and pessimistic analyses and show you a view with the result of your three-point analysis. It’s a worthwhile exercise if you’ve not tried it before and, if you do, you’ll be ahead of the pack and have a taste of project management life from Down-Under.

G’day mate!

Haven’t we all had one of these moments?  Cancelling a project is a tough call and now, thanks to Scott Adams, we see how it’s done behind the scenes!

When I first got started in the project management software business, I knew that what people needed to be trained in to be a good project manager was the Critical Path Methodology calculation. If only someone knew this magic algorithm, they too could be a good project manager. I still have course materials which include exercise after exercise about how to do forward and backward pass of the CPM calculation.

How far we’ve come.

I’ve had the pleasure lately of working with some people at McGill who are attending classes to learn more about being a project manager. It’s an advanced class so we’re not spending much of our time on learning how to manually calculate a project schedule. After all, there are many tools which can do that for us. Instead, most of our time is spent on the so-called soft skills that a project manager needs to survive.

I’ve often said that someone who wants to implement organizational project management (these days the most popular term for this is EPM or Enterprise Project Management) needs to be 50% technician, 50% therapist, 50% teacher, 50% mentor and 75% Guru. It’s no small challenge. The problem is that in almost all cases, people are swimming upstream when they want to deploy project management as a common process across the organization.

We’ve got three clients who’ve just hired someone to head up their new PMO and EPM deployment initiative. I’ve got great sympathy for the people doing the hiring. How do they find just the right person for this?

I’ve been thinking about what survival skills I’d go looking for in such a key person and I thought I’d share them this week here.

Presentation skills

It’s amazing to me how many people in business are awful presenters. This is very much a nurture skill (as opposed to a nature skill that you got by virtue of your DNA). Virtually anyone can learn to present adequately and most people can learn to present very effectively. There are public speaking courses all over and we’ve often sent our staff to them. There are a few basics of presenting that are so simple that no one should be without them. Here are just a couple:

1. For the love of God, please, please don’t read your PowerPoint slides. If you do what you’re silently saying to your audience is, “You must be illiterate. Thank goodness I’m here to read these for you!”

2. Make sure people can see what you’re presenting and hear what you’re saying. That includes volume of your voice, distractions such as outside light or noise, people talking etc. Never, never try to talk over someone else.

3. Know who you’re presenting to. If you don’t know by the time you start. Use the first few minutes to make sure you know who’s in the room. If you don’t have any clue who’s in the audience, it’s almost inevitable your comments will be off target.

Negotiation

This is key to any project manager’s job but it’s particularly critical if the person we’re talking about will be changing the organizational culture. I’ve never seen an EPM environment created because of pure authority or just at random. It inevitably comes through generating a consensus and being able to negotiate is the central skill required for that.

Organization/Document management

This may be one of the most important personal skills. I’ve seen people who are wonderful orators and fabulous hand-shaking people-people but they can’t find a single thing on their desk or on their laptop. If you want to be the person who will create a PMO then you’ve got to be all about the process and that means being able to track the documents that are a part of what you’re creating. `

Basic Technology

I can’t tell you how many people I meet who don’t know how to effectively use Word or any word processing software. Same goes for Excel, PowerPoint and Outlook. The result is, that I find people writing emails, letters and other communications that are terribly formatted and very ineffective. Training for these tools is available from your nearest bookstore and that means there is little excuse to not have these skills. Using your basic desktop product skills is so fundamental, I don’t see how someone can advance without them.

Leadership

Ah, the most elusive of all. There are so books, courses and conference sessions on leadership that you can feel swamped with too much advice on how to achieve it. I think this is partly because leadership is related to so many other skills and, in the end is more of a way of being than a particular skill. That being said, there’s lots you can do to be a better leader. Being prepared, taking initiative, offering to be responsible for something are all actions that make a difference. People also have to have some desire to lead as there’s no number of books, the reading of which will make a leader if there’s no desire. So I’ll have to put this into a category of personality traits rather than skills.

While we’re talking about personality traits, a desire to learn is critical. When we hire new technical people in our firm, we tell them a few things during the interview process. First, we let them know we only hire people who are ‘quick studies’; people who learn quickly. Then, we tell them that more important than that, is that they will never learn enough. Their training will never be over. The people who succeed in our line of work are reading constantly. After all, you’re reading this and have done for the last few minutes in order to get this far. I do the same. I’ve easily got an hour a day of reading in my industry which I need to just to keep up; to keep constant. People who are looking for the quick fix (can’t I just take the blue pill?) in training will have a much tougher time being successful in deploying organizational project management.

You’ll notice I’ve not mentioned any of the traditional technical skills in project management. Do you need to know about time management and scope management and change management and risk assessment and quality control and so on? Of course you do. If you’re going to be working in the project management domain then you need to be not only very knowledgeable about the building blocks of project data but also have experience with using them.

But, if you’re going to be a person who deploys project management not just for yourself but for others and, in particular, if you’ve gotten the job of deploying project management for an organization, then avoid your soft skills at your peril.

As the economy slowly recovers project teams are facing an unusual challenge. Management is coming to project offices and to product managers and asking them to ”restart“ projects that were suspended due to economic concerns some time ago.

Restarting a project can be infinitely more complex than starting it originally. The original project plan might have been created with great care over an extended period but the assumptions that play behind the scenes in any project may have changed dramatically. Management may not be aware of the challenges the project may face. Here are just a few:

Those experts? They’re not available
The personnel that may have been in place when the original project plan was created may no longer be available. They may now be involved in other projects. They might now have moved positions and be in other roles within the organization or they might have left the organization altogether during restructuring. It is not uncommon to find that when restructuring is done on a large scale that one of the most common departures are people who are near retirement age. This is particularly true in large organizations. Not surprisingly, these long standing employees often have unique key skills and experience that the project was counting on when the original plan was created.

You’re going to have to go back to your resource plan to see what has changed and even redo a skills inventory if there have been big changes.

Those sub-contractors? They’re doing something else
Suppliers of all kinds may have changed in the last two years. That includes sub-contractors that you might have expected would be available at critical moments of your project. Also, the suppliers that you used to deal with often might no longer be in a position to supply the expertise, product or service you were counting on. In some cases, the changes might be positive ones. Some suppliers may have used the intervening time to sharpen their operations and now be in a position to supply what you’d counted on at a reduced cost or with less delay. Either way, you’re going to have to go back to any sub-contractor assumptions in your schedule to see what may have changed.

Where’s the funding?
Funding options have dramatically changed in the last 2 years. Money might not be more expensive to get but it is almost certainly harder to get. This can result in significant challenges getting funding from the same sources or under the same conditions that existed two years ago. If your project is multi-national then funding sources may be even more complex in different jurisdictions.

Game changing regulations
While the private sector has had tremendous challenges in the last 2 years, the public sector has also undergone changes of a different sort. Governments are requiring more transparency of anything they fund and with so much recovery money coming from governments recently, you may find you have more regulations on reporting that you didn’t have to deal with previously. Make sure that you do a review of regulatory and permit requirements that may have changed on your project.

Governance
Sounds like government but it’s not. Governance is about good management and there’s a newfound interest in it in the last two years. “What will we get for our money?” is something that every responsible manager now asks. That’s true not just for your own management but also possibly from your client, the bank and the government. Your reporting requirements for your project may have to be adjusted to comply with new requirements.

Return on Investment factors have changed
I’ve been talking about the “I” in ROI while discussing how the costs of the project may have changed. At the same time it’s worthwhile to think for a momeny about the business key performance indicators that may have changed. For organizations that use a Stage-Gate structure, the metrics that got the project through 1 or 2 gates may no longer be accurate. Is the product or output of this project going to produce the same value as it was expected to when the project was suspended? Are the prospective clients still prepared to pay the same amount or purchase the same volume of the project’s product as you had expected in your original business case? This has to be reviewed.

It’s not all bad news

For some organizations, a pause or slowdown is an opportunity for the Project Management Office to shore up the project management expertise and tools. Many PMO’s I’ve been in contact with in the last two years have been using the time to expand project training, to deploy project management products and to develop project management best practices. Some progressive organizations used projectd management during the economic downturn as a method of being more efficient. This paid immediate dividends while the company was under pressure to perform more effectively but their are additional dividends to be had as the economy improves.

Being efficient never goes out of style.

As projects need to be restarted in these organizations, the newly developed best practices can be applied along with any new tools. The additional project management training these organizations have aquired can be used to review those old project plans from a new perspective.

As organizations slowly open the taps of production again, it will fall to project management to ensure that we don’t assume we can just start up where we left off. It’s a relief and a happy day when management makes the call to say, “Time to get restarted.”

But…

Re-starting is often going to mean Re-planning.