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.

Whenever I am involved in the deployment of an enterprise-wide system I’m reminded of an analogy attributed to Buckminster Fuller (You remember Bucky. He’s the fellow who came up with the idea of geodesic domes.) Anyway, the story is about turning a ship. You see, when a ship is very large, say the size of a super-tanker, the size of the rudder to turn it must be correspondingly large. The problem is, that a ship such as this underway causes so much water pressure on the rudder, that the force required to push it against the water to turn the ship is incredibly large. So, someone very clever invented the “trim-tab” A trim-tab is a little rudder on the rudder and it seems that if you push that rudder in the opposite direction you want to go, the main rudder can be moved outwards with almost no effort at all.

Ok, cute story, but what does it have to do with project management software and enterprise systems? Well, everything.

The biggest issue with deploying an enterprise system is not the perfect selection of functions against requirements, it’s changing the corporate culture. For anyone working in a medium to large sized organization, you know that comparing the intractability of a corporate culture to the momentum of a supertanker is not at all inappropriate.

Over the past few years I have seen many, many fine individuals break their spirit over this issue. They know they’ve picked a product that will answer their firm’s needs but are unable to get it implemented throughout the organization. No matter how much force they mustered, it was never enough to ‘turn the ship’. The selected software ends up either completely abandoned or being used just by the core implementation team, another element to add to a fractured systems environment.

In those organizations where an enterprise project control system has been successfully implemented, inevitably, the corporate culture was changed a step at at time.

Operational procedures are business’s ‘trim tabs’ for corporate change. Now, lest you leap forward and think, ‘Great, tomorrow I’ll get started on a new procedures manual with hundreds of procedures to make people comply with our new corporate culture.’ or that you think you can mandate a corporate culture change by simply making a procedure called “change your cultural habits”, think again.

The changes that will be most effective will be insidious yet impactful. I was recently privileged to be in a conference session with a number of experts in the deployment of enterprise-wide project systems. A couple of their comments are worth noting. One of these experts described how their organization had designed a “knowledge base” of lessons learned on past projects. For some time the knowledge base had been established yet no one ever seemed to have the time to contribute to it. If there were lessons being learned, they weren’t being made available to future project managers.

The expert in this organization (you’d recognize this three-letter firm if I mentioned it), decided on a small change in procedure. Inside the contract for the project management consultants, a new line was added, identifying the contribution of lessons learned to the knowledge base as a deliverable part of every future contract. Hmmm, guess what? Suddenly every project management consultant seemed to find some new time. No contribution, no final payment for the contractor. This wasn’t a big corporate decision, Moses was not required to come down the mountain with stone tablets, it was a little one-line change to a contract template that turned the ship… a trim tab.

The other expert in this session had project managers who were not contractors, they were employees. Holding back payment in this scenario could not be one of the options. In this firm, a similar impact was made. On the project manager job performance review form, a new line was added. Project managers were now to be graded in their contribution to the project management process. Surprise, surprise, within a few months, project managers seemed suddenly interested in a process that they would have been hard pressed to identify in the past… trim tab.

What I like about both of these examples is that they started surreptitiously. All too often, when organizations attempt to implement a system company-wide, it starts in one of two ways. If the system originates from the mid-levels of the organization, then it rarely comes with the authority to deploy with every department and every user and often stalls within a close-held group. If the system originates from a high-level of the organization, then all-too often it comes with too heavy handed an approach. While upper management almost always has the authority to impose a structure, if it tries to impose a change in culture without considering the human impact, it runs the risk of creating “covert saboteurs”, staff who pay lip service to the new system yet make every effort in the background to stick to the old ways.

Culture change can be a sensitive thing. If imposed too quickly or too drastically, employees may feel threatened, their familiar world turned upside down. The most impactful changes are usually those which sneak into the system and the best way to deliver those changes is through small changes in procedures. Changes that at first glance don’t seem to change anything significant.

If you’re interested in change in your own organization, start looking for those trim tab opportunities. Ask yourself what change in function or practice would result in behaviour that would contribute to the deployment of our enterprise-wide system. Then, before implementing that change, ask yourself what the likely reaction would be to implementing that procedural change. If the reaction is likely to be major, you’ve not found a trim tab, you’re trying to push the rudder itself.

Of course, sometimes there’s simply no choice but to go with the brute strength approach. For example, organizations faced with a shortening calendar before the year 2000, find themselves implementing complete overhauls or replacements of core organizational systems. Where changes might have been better implemented over time, these firms must drive quickly, pushing the system in where it is required. If this is the scenario you’re facing, then other methods can mitigate the potential negative impact. Skilled ERP implementors use focus groups and familiarization sessions in part so that nervous recipients of the new system can express their concerns and have their issues answered by people with the control to deliver answers.

No matter what your situation, keep looking for those unique and powerful opportunities to enhance the situation in your own organization through the smallest of changes, the trim tab.

One of my favourite advertisements for project management software over the last couple of years shows a harried project manager with his head in a photocopier trying to clone himself in a desperate attempt to get more resources for his project. It’s a sentiment almost everyone in the IT community can sympathize with lately. If there is a CIO in the country ready to say “I’ve got more than enough resources,” I’ve yet to meet him.

The tradition method of increasing resource levels has always been to just hire more. Yet that option is becoming increasingly difficult for various reasons:

First, resources are often scarce. With IT project being ever more complex, programmers for varying development environments, systems analysts and others are sometimes hard to find. Recruiting and retaining key staff has become a full-time job for some managers.

Secondly, certain key skills are harder to come by than anything. One of the things that IT project managers come to know quickly is that the resource they absolutely need is the same person every other project manager in the organization needs.  The particular combination of knowledge, skills, knowledge of existing systems and experience makes certain technical people unique.

With the traditional method of resolving resource conflicts cut-off, many CIOs are looking to become more effective at managing what they have. Getting the most out of your resources is one of the promises of project management software and so it is no surprise a that the Project Management Institute is seeing more new members from the computer industry than any other.

So, what can you do to get the most out of your resources? Here are a few suggestions:

Find out what people are actually doing
This is no small thing. In many organizations, the amount of time “lost” in unallocated time is startling. For these organizations, there can be tremendous improvements in efficiency just in determining what people are spending their time on. An electronic timesheet system designed for project use finds a good target here. The system should be able to restrict the permissible charge codes to only those which have been created and authorized. This prevents countless hours from the dreaded “999 – miscellaneous” code. In one organization we’ve done some work for, implementing an electronic timesheet system “found” $60,000 worth of hours in the first month alone.

A corollary to this is to ensure that people are doing what they were scheduled to do. When we implement an enterprise-wide timekeeping system, managers are almost always amazed at what people are spending their time on. In some cases, staff members start working on tasks which were never part of they original project specification but that they think will be important.

Prioritize
Getting the right people to work on the right task is the next challenge. Project Management software which can identify tasks which should be completed before others and tasks which will have a greater impact on the total project (or projects) schedule allows a department manager to keep people focused. Applying an 80/20 rule to the problem says that 20% of the tasks will likely take 80% of the time. No problem if these are the most critical tasks on the project but in example after example, we come across projects which are running late where a significant proportion of the development team are mired in program cosmetics which were never part of the original specification (cute though they may be). A very clever coach once told me “work-ability before impeccability” telling me that while impeccable work was desired, just getting it working was ultimately more important. I’ve heeded the lesson since. When we do development now, we get the function working, before we add the spice, bells and whistles.

Resource Levelling
Some project management systems do a good job of providing resource levelling analysis. This analysis tells the manager where tasks will have to be scheduled in order to get the earliest possible date with the resources available. An advanced package will include the ability to show both a time-constrained analysis and a resource-constrained analysis at the same time. The time-constrained analysis assumes that additional resources could be made available but that the project schedule is inviolate. A report of this type of analysis will show the additional resources required in order to accomplish the schedule. The resource-constrained analysis assumes that no additional resources are available and that the schedule can be extended. A report of this type of analysis will show how long the schedule must be extended in order to complete the work with the staff available.

Neither of these analyses should be taken at face value. There are many techniques for advancing a schedule with limited resources including re-sequencing the tasks, changing durations, applying overtime and so on.

What is useful here is to find periods of peak resource requirement early enough to allow the manager to make preparations or to mitigate the problem. If there is enough notice, the manager can make a remarkable impact on the availability of resources for other tasks. Options for the project manager to consider include sub-contracting work, changing priorities of tasks, putting some low-priorities on hold or not starting some low-priority projects which might have otherwise taken up time. One of the things to consider is doing some work in advance in order to take advantage of some under-allocated time even if logically some of that work wouldn’t be done yet. For example, one wouldn’t typically start writing documentation until a piece of software was substantively complete. However, it might be possible to write quite a lot of system documentation and user documentation based on in-house standards and specifications. Even if some of the work had to be edited later, you would have gotten a huge jump on an area of a project which is typically a vulnerable point for project delays.

All of these techniques won’t create new staff in the morning but they have the potential to create tremendous efficiencies in resource management. Implementing any or all of these will almost always involve culture changes in your organization and, as I’ve said before in these pages, culture changes are not the easiest thing to implement. Take it one step at a time and make sure you involve the whole staff so that people know what the potential gains are for everyone if your operation becomes more efficient.

Of course, if that doesn’t work, the photocopier option is still available. It just seems, no matter how many times I stick my head in it, the copies that come out never seem to do as much work as I do.

I’ve been enjoying Scott Adams Dilbert comic strips for years.  They’re a treasure trove of laughs for people in the project management or timesheet software business as I am.  Adam’s Dilbert website has too many old strips to choose from so here’s just one that had me chuckle today.

“What-if?” These are the two words most heard in the project management industry. Everyone on a project has his own “what-ifs”. Each member of a project team has his own perspective. But what everyone is referring to here is targeted at the same thought process. This is an aspect of contingency planning.

Good project managers, just like good managers of any kind, are constantly thinking of what might happen that isn’t currently planned for. For the most disruptive of conditions, they will likely have already mapped out an alternative strategy for dealing with the issue. This is fundamental to being a proactive manager. Lesser managers often find themselves managing by reaction or by emergency. This is a result of a contingency occurring for which there is no immediate solution.

Risk is often thought of in terms of insurance but it fits very well in a project management context. For those who are involved in schedule and cost management there are many tools now available on the market that can help.

There have been risk analysis project management tools available for your PC for over 10 years. Oracle’s Primavera has Pertmaster, a system which is designed to provide risk analysis and reporting for project schedules. @Risk and Risk+ are two products designed to provide similar analysis to Microsoft Project users. Deltek has WelcomRisk designed to add Monte Carlo risk analysis to its Open Plan product. This

So what does this software do? Does it tell me ho risky the project is? Does it somehow manage the risk for me?

First of all, risk analysis software does not do risk assessment. What it does is take the risk you assess to each task and provide analysis of the combined data to give you a view into areas of the project which might not otherwise grab your attention. What is this analysis? One of the most common algorithms is called Monte Carlo.

Okay, what’s Monte Carlo? Isn’t that where everyone goes to gamble? In fact, that’s exactly what it refers to. Here’s what happens in the Monte Carlo method: The user first inputs the minimum, maximum and best-guess of each task’s duration. In addition, the user inputs a type of curve. Examples of such curves might be a Bell curve or a Uniform curve.

The analysis is, in fact, just a critical path calculation. The difference is that it is done many, many times. And each time a task is considered, instead of just taking the original duration, the algorithm “rolls the dice” and uses a random duration. The randomness is controlled by the input. The algorithm uses the range between the optimistic and pessimistic durations and the curve to determine which duration to use. A Bell curve, for example, will tend more to the middle of the range where a Uniform curve will have an even chance anywhere along the range. The analysis continues through the project then returns and does it again. Often an analysis will perform 100 or even 1,000 passes through the project to deliver adequate results.

The algorithm returns information on each task as well as additional information on key tasks. So what’s the point? Well, consider a hypothetical project. In our project we have five tasks in sequence. Each task has four days of float or ‘slack’ time. Float is the amount of time an activity could be delayed without delaying the project itself. A task with no float is considered ‘critical’.

Okay, so we have our five tasks in a row. Imagine that the first task is three days late. Now the next task must have only one day of float. If it goes a day late, then the next three tasks in the sequence immediately become critical. A normal critical path methodology analysis, such as can be found in most project management systems, will never show you this information. However, a Monte Carlo simulation can find it easily. By rolling the dice, some of the time the first tasks will come up with a longer duration.

In combination with various reports, project managers can no be presented with two kinds of information. First, a listing of tasks which have a high degree of probability of becoming critical at some time in the project. Secondly, for key activities, a confidence curve can be generated showing a histogram.

There is another aspect to these reports which may be the most useful of all. This involves the trend of these analyses over time. Let’s consider this in basic terms.

On the last day of the project there is a 100 percent chance that the project will finish that day because, well, because it just finished. On the first day of a project, a risk analysis might tell that that the project is due to finish no earlier than Jan 1 and no later than July 1 of next year, a six-month range.

Each time the project is updated, the “risk” or the range should get narrower. Well what if it doesn’t? This can be a major indicator to a client or to the project manager that there is something severely amiss. It almost guarantees that there is a change in the project scope somewhere in your future.

Going through the extra effort of risk analysis isn’t often required on every project.  But, when you’re wondering what the impact is on a project with an unusually high number of risky assumptions, Risk Analysis software can go a long way to showing you some empirical results.

It was once a dark art. Those of us who practiced it were considered no less than fortune tellers, connected somehow to the supernatural, performing our strange rituals of calculations which once seemed no less outlandish than the science of alchemy seems now. When we were done we would create colourful displays of our results, showing that this project or that would now end 2 months earlier or 2 months later and there was no one present who could say otherwise.

Times have changed. Now project management methodology is taught as part of all management curriculums. Critical path calculations, barcharts and activity network diagrams are now as common as finance reports. Managing by project has become one of the hottest new trends in today’s management circles. It seems that everyone is doing it. There’s lots of incentive. The last 15 years has seen a period of rapid increases in efficiency in IT thanks in part to the drive for project management during the Y2K period. A more global economy and startling improvements in communications have allowed companies all over the world to compete for even the smallest amounts of business. No matter what industry you’re in, you’ve got to be able to deliver short product runs, be able to survive on the slimmest of profit margins, be as efficient as possible.

This trend towards management by project has allowed organizations of all sizes to compete on a more level playing field. Even a small organization can deliver an efficient project. But what does it take to manage an organization by project? Is it a new software choice?

The short answer is no. Projectizing a business starts with a structure change.

Most organizations have grown up as organizationally structured. If it was a family business to start with the most common structure is hierarchical. A family head at the top, vice-presidents below, department heads below that and so on. Even once the family is no longer involved, the basic structure will carry forward on its own momentum in a top-down structure. Fifty years ago, this was virtually the only management methodology.

Some organizations start in a more structured fashion or grow from hierarchical management environments to accommodate much larger companies. These groups may become more of a matrix organization. In a matrix, some managers are responsible for managing the departments, while others are responsible for getting work through the system.

A completely projectized organization would have no responsibility with a department. All responsibility would rest with the project managers.

Each of these methodologies has benefits and drawbacks, but they’re each worth considering for the advantages in efficiency they bring.

A hierarchical organization is typically able to change very quickly. Once the top tier of the company is convinced that change is required, others in the organization are informed and are expected to comply. The big disadvantage of course, is that any input from the lower levels of the organization which might have been useful is never considered. Also, if a change in management results in a less commanding presence than is expected, the entire organization might suffer (I’m sure I’m not the first person to wonder what Microsoft will be like once Bill retires).

In a matrix organization, there is a benefit of dividing responsibilities and, hopefully, getting more input from more management personnel. The department managers are typically responsible for the training, availability, hiring/firing etc. of their staff. They provide an expert-level service for work to be accomplished. The project managers use those services by requesting personnel for particular projects. They’re responsible for delivering the project. The downside to a matrix organization is the inherent conflict within the organization it creates. Perhaps in a perfect world this would be the most effective but in some companies, the pull of some managers to try to retain as much authority as possible makes the structure a breeding ground for upset. In a multi-project environment, some project managers will complain that their project isn’t getting a high enough priority for resources. Some department managers will complain that the project managers are “hoarding” their people. There is certainly more maintenance to the structure in a matrix environment.

In a project environment, there is the benefits that come from single-mindedness, concentrating on the project and its deliverables. The downside to this structure is the lack of belonging. Personnel wonder what will become of them once the project is completed and this sometimes leads to personnel ongoingly looking for work. Also, there is little allowance in this structure to take the lessons learned from one project and apply it to the next. This type of structure is most commonly found in mega-projects or in organizations which have been formed for the express purpose of completing a particular project.

Over the past few years, more and more companies have been leaning towards giving more authority to the project management aspect of their business. There is a desire from many CEOs to at least be able to track the company by project if not manage all personnel that way.

From a systems perspective this can be a huge challenge. An organization whose systems were built up over a period of years to collect, analyze and report data in one type of structure are often less capable of delivering the same types of results for another. Accounting systems, scheduling systems, payroll, even timesheet systems are structured to the needs seen by their developers at the time.

If you are in an organization which has determined that it is changing its basic management structure and you are responsible for some aspect of that change, you are likely going to have to deal with some systems issues.

Start by identifying what you are doing now and which data systems and reports are going to be altered. Sometimes this identification is very simple. Management might, for example, have made a new request that from now on, labour and materials costs will be reported project-by-project. Sometimes you’ll need to dig a little deeper.

Next start looking at how you will be able to collect that data by project rather than just by department. Don’t drop what’s working already! If you’re currently collecting timesheets from the department manager for instance, don’t assume automatically that you’ll now collect them by project manager and that the department manager will be dropped from the loop. What you’ll probably find is that there is some requirement from both sides to have access to that data.

When you start to implement your changes, go slow. Start with one aspect of the total structure. Wholesale changes all done in a single moment are almost always destructive. Make your small change and see how it affects the rest of the company. You may find that for some period of time, you’ve got to do double entry to take care of both aspects of the business. Grin and bear it. Keeping what’s working operational for awhile is great insurance against issues you may not have considered in the new structure.

You can continue to implement area by area following this kind of plan until you’ve reached a level which is comfortable for the entire organization. It’s entirely likely that this level is well before a fully projectized organization yet is much more projectized than you are already.

To help stabilize that structure, one of the more important things to do is to determine that new systems and new packages being considered and implemented will have the project-oriented functionality required for future moves in this direction. This is particularly important if, like many organizations, you are in the middle of replacing your core financial and management systems to become Y2K compliant.

The perfect balance for a particular organization is probably a balance between these structures and each organization must determine for itself which way to go. Changing software itself might make you projectize-able, but it’s going to require a change in management structure to make you projectized.