If you’re implementing a project control system, or any enterprise-wide system, one of the most significant elements to consider is the product champion. Without a knight (of either gender) to champion the cause, the chances for a successful implementation drop dramatically.

So what is a product champion? It’s a person who is held to account for the success of the system implementation. It’s a person who on a given day stood up and said, “You can count on me. I’ll make sure that this system works for us.” A champion, just like a Knight of the Round Table has to be backed by the king. Without any authority from management, few people would (and no one really should) take on being accountable for a system implementation project.

There are several key elements to implementing any enterprise-wide core system which could handicapped or even block a successful implementation. We see this almost every day in deploying our enterprise timekeeping system or project management software.

These elements include:

Lack of Planning
Can I say this enough? Make sure you manage the implementation of your project management system with a project plan! We estimate that 4 out of every 5 implementations are attempted with little or no planning whatsoever. Without a project plan, the chances of being successful are slim. Without clearly defined goals, a well thought out budget, a manager who is committed to achieve those goals and management support for making the plan work, there’s little hope of getting anywhere. One of my favourite Chinese proverbs says “If you don’t know where you’re going, any path will take you there.” If there’s no clearly identified goal that everyone is committed to then how could you achieve it?

Duration of the Plan
There is an illusion that a project management software implementation (and many other enterprise systems) are complete as soon as the software is purchased. For anyone who has been involved in deploying such a system you know that purchasing the software is usually just the start of the most difficult aspect of the implementation process. If there are unrealistic expectations that the project will only last a few weeks, or a couple of months, then as the implementation drags into its sixth or seventh month, it may lose critical support. An enterprise-wide implementation for a mid-sized company can easily last a year. ERP implementations are often targeted at 2-3 years. This can test the most patient of supporters. Without the champion keeping the project alive, keeping people enrolled in the project and keeping the group enthusiastic about the end result, focus will ultimately be lost.

Lack of long-term support
Many things can affect long-term support for an implementation project. Management changes where responsibility shifts from one manager to another can be a key factor. Staff changes which change the composition of a selection committee or removes a key resource can have a dramatic impact. Before the process even starts, it should be made clear that the people signing on are signing on for the duration and are made aware of how long that support will need to last. A Product Champion may be the only continuity in a project which sees many changes around them. It is their responsibility to keep the project on track.

Lack of Focus
When you’re starting your system-wide implementation project, everything will seem very simple. After all, the core team who are starting the process will be comparatively simple to bring to a consensus on varying issues. Once the deployment of the system starts however, life will take a dramatic turn. Suddenly every personal, individual, conflicting interest in the organization surfaces as “must-do” requirements. Interests which for a variety of reasons will be defended to the utmost by the people who support them. It is here that focus will become the most important aspect of the implementation. Without a central figure to reaffirm the project’s goals, these divergent interests can drag the project right off the rails.

Power sharing
While I’m sure this is not an issue in your own organization, I must confess I’ve seen this occur in some organizations across the country. As it becomes apparent to people throughout the organization that the enterprise-wide system will actually impact them, some people will perceive this as a threat to whatever “power-base” they’ve created by using their own personalized systems. These people may have a great resistance to fully participating in the new system. Those who are very public about their concerns are the easiest to deal with. The most difficult (and I’m confident that most of you have never experienced this) are those who publicly proclaim their support of the system while in the background do just the opposite. The only way of overcoming this phenomenon is to have a central person who enrols or re-enrols these people in the vision for the whole organization, in the benefits for everyone that will come from cooperating. Someone who has the knowledge and authority to resolve their concerns. The person most invested in making this work is always the product champion. This particular subject is dealt with in much more detail by Peter Senge in his book “The Fifth Discipline”.

All of this points to a single solution; an individual who will hold the goals of the project against any and all resistance; someone who believes in the project and who knows they will deliver; someone who has both the desire and the support to make the project successful.

“Oh wait,” you say, “we’ve got just the thing. Our implementation committee are absolutely committed to the project and include all kinds of skills. Surely this is even better than your ‘product champion’”.

Sorry. Not so. A committee is one of those entities with many legs and no intelligence. It almost always results in management by consensus or worse. The keyword here is accountability. You can’t hold a group to account. You can make them responsible but there’s no way to hold them to account like you can with an individual. If you’re an executive sitting with your implementation committee and wondering if the project has any chance of making it your request should be this, “Would the person who is ready to personally promise me that this implementation project will be successful please stand up.” That’s your product champion. Don’t get started without them.

Given how project management software has taken advantage of today’s graphical age, there is a plethora of possible reports available for users of such systems. I’m always amused when we put such things as “200 reports included” or “thousands of reporting combinations available” in our marketing literature. Is this supposed to make people productive? As I work my way across the country and in different parts of th world meeting people who struggle with their own implementations of project control systems it’s easy to see why a system with hundreds of reports could be at once a great system to implement yet overwhelming for virtually all users.

When you start to distinguish the different kinds of audiences for these project management reports and the different kinds of reports available, the deployment of these systems makes a little more sense. Let’s start with the different types of audiences.

First of all, the users alone are an insufficient definition of the audience for the output of a project control system. These full-time or power users must be included, of course, but almost always, the users of a scheduling system are users at all because of the request or requirement of someone else. The users however will require detailed reports that allow them to identify work, debug input into the system, sequence and organize raw data into identifiable categories and orders and analyze the results of any analysis. In addition, this group will need to validate any other reporting into the system.

Another clearly distinct level of audience is the grass-roots input to the system. Some of these front-line personnel might use the system or use a “lite” level of access to the system but they will not typically be full users. The interest at this level for detailed analysis of the schedule will be low. Users at this level will be more interested in lists of tasks; in turn-around documents or forms to fill out while in the field and in simple schedules of what is expected of them next. How the system actually figured out what is expected next is of little use to them.

The ultimate ‘clients’ of many project control systems is another identifiable audience and that is the ‘Executive Suite’. Here the interest is not in the detailed analysis but in the synthesis or results of that analysis. Reports are expected in summary form with the all too elusive “One-Page Report” or an executive Dashboard being the ultimate goal for most executives. Trying to impress executives with a 20-foot flow chart of activities which stretches around 3 walls of the conference room will generally be unsuccessful.

There are likely several other potential audiences for project control reports. Project sponsors for example or the client themselves. Regulatory authorities often have specific requests and, if you’re in the defense business anywhere in the world, you’re likely to run afoul of Earned Value reporting standards. For each group of readers of the system’s reports you’ll need to look at their requirements separately.

Let’s turn our attention now to the kinds of reports which might be requested. Every project control system will have different types of standard reports but virtually every one of the systems on the market at virtually every skill level will include the following categories of views or reports: List reports sometimes referred to as spreadsheet reports, Barchart or Gantt views, Curves and Histograms, Activity Flowcharts, sometimes referred to as PERT, CPM or Network Logic diagrams, and Work Breakdown Structure (WBS) tree diagrams. There are a number of other more esoteric categories (scatter diagrams for risk data for example) and a variety of hybrids of different views but this is plenty for the moment. Let’s take these categories one at a time.

List or spreadsheet views are essentially text-oriented reports. These reports are organized in rows and columns just like a spreadsheet (hence the name) and these days are just as likely to look just like a spreadsheet when they’re output. Spreadsheet reports are useful for pretty much every audience depending on their content, their level of summary and the amount of data on them. A few products offer multiple lines of data per activity, most allow columns to be customized but only in one line per task. For executive reports, look for data to be summarized to a level of one line per project.

Barchart reports are sometimes referred to as Gantt reports. (After Henry Gantt who is credited with inventing them.) These reports are organized with tasks or summary tasks on the left with various columns of data and a bar or multiple bars against a date scale to the right. With abilities to modify what bars refer to what level of data, many different effects can be created here for different audiences. Typically, this is a good tool to use at the executive level if the system is capable of summarizing to one line per project and at the grass-roots level for individual schedules. Power users won’t often use a barchart except to validate that the schedule “looks” the way they’ve designed it.

Flow Charts are sometimes inaccurately referred to as Logic Diagrams or PERT charts after the charts designed for the PERT analysis method which is seldom used anymore. They show data at a detail level with one box per task and a line between tasks which are sequenced in order. In a good-sized project, this can add up to a lot of paper if you output the data. Still, this is the absolute best way to view the sequence of tasks. The flow chart is best targeted at serious users of project management software as the information contained in each box can be confusing for anyone not familiar with critical path methodology theory (that’s the name for the algorithm most often used to calculate schedule dates). In any serious project, there’s usually a “war room” allocated for the project team which should sport one of these diagrams as wall-paper. It’s a great tool to use while updating the project as you’ll immediately see the impact on other areas of the project when you change progress on a task. Also, having such a report ensures that proper project management techniques are being used and that the system is not simply a “barchart painter” regurgitating dates already specified by management.

Curves and Histograms show cost, resource and risk data. As summaries they are useful for management, in detail they’re of use only to experienced project managers. There’s likely no one at the grassroots level who wants to see the resource levelled histogram of data.

WBS diagrams are hierarchical tree diagrams just like an organigram. In a work breakdown structure however instead of an organization breakdown, you’re showing the breakdown of all work on the project. WBS diagrams are used to clarify other data and as such are best targeted at the power user.

In the end the system that you create should only have a dozen or so reports that are used with any frequency. These reports may be standard, out-of-the-box reports or may be customized using the many tools to be found in project control systems these days. Rather than looking for a system which has more reports than the next one, look for categories of reports. Does the system support the kind of WBS you’d like to see and are the customization tools there to alter it to exactly what you need. Finally, in this graphical age, see if the reporting view you like so much is also interactive. Can you display your data in this view then manipulate the data right on screen?

It is a lament I hear almost every week. “How can I convince my management that we need to implement more project management?”

It’s not universal, of course, but the number of organizations where executive level support for the project control environment is either non-existent or openly negative is remarkable. Even more remarkable is that these same organizations often have executive level commitment or interest in better managed projects. What is it about implementing project control that makes executives so reluctant to take it on?

The issues break down into several categories:

By far the most significant category is a lack of understanding. Even with the advent of desktop project management systems such as Microsoft Project, the science of project management is complex and not grasped instantaneously. Part of the project is that project management and project management systems have become synonymous with project scheduling and project scheduling can be an involved subject. Network flow diagrams, Critical path scheduling, arcane terms such as “Total Float” or “Lag” make the subject even more daunting. Acronym such as “BCWS” don’t make it any easier for those people whose involvement in the actual workings of the project management process will be cursory at best. (By the way, BCWS stands for Budgeted Cost of Work Scheduled or, “the budget”).

Is the answer to this education? Special classes to train managers in how to calculate the Critical Path of a project? I think not. Why a manager should know all these terms is somewhat beyond me. In almost no cases will this make the person a better manager. Management’s input into the project management process is not to analyze the intricacies of a detailed project schedule.

To compound this problem, a second favourite category is the complaint of many project managers and schedulers is that on the subject of project management their own executives seem to have the attention span of a gnat! Decisions that, for a project scheduler involve detailed consideration of reams of data simply do not interest executives. In fact, the most common request by executives of their project managers is for single-page reports.

This problem can best be seen in public service. A cabinet-level politician or bureaucrat is so inundated with the day-to-day details of their department that they are often given no more than several minutes on a monthly basis in order to make momentous decisions on multi-million or multi-billion dollar projects. It is not that these people are not interested, just that this is the amount of time available for this type of decision at this level. I’ve seen several situations where this level of government official is given 3-5 minutes to give a go/no-go decision on continuing or cancelling a project worth well over $100million. To the project manager or scheduler, this lack of executive attention must be unbearably curt. Yet it is as common in the private sector as the public.

A solution? More time you say? I’m afraid not. Even doubling the amount of time spent at this level will still result in a ridiculously short amount of time spent analyzing the data. The problem is a difference in perspective.

Yet the demand in the executive suite for more effective management of projects is intense. Economic pressures increase the need for even more efficiency every day. For those executives or management teams struggling to understand what they must do in order to implement such systems, other differences in perspective continue to make selling project management to management difficult.

One of these differences in perspective is the notion that choosing the right software will solve the problem. The combined world-wide marketing efforts of the project management software hype-meisters leaves promises of effortless “enterprise-wide” project management on the pages of almost every major computer publication in existence. (Yes, I know, I’ve been guilty of this myself). With the current craze for ERP systems, and Office Suites which include project management functionality, this kind of promise is held out to executives as the holy grail of solutions to their woes.

Does this mean that software will make no difference? Of course not. But software is only one aspect of a solution and, in my experience, software implementations which occur in a vacuum devoid of management support, process changes, cultural consideration and a commitment to change inevitably result in failure. No, software alone does not solve this problem.

If you have been tasked to sell project management to your own executive or, if you are part of an executive and wondering why you should be interested, here are a few factors to consider:

• · First and foremost, distinguish the perspective of the players involved. It is inappropriate to think that the interests of an executive responsible for the outcome of dozens or hundreds of projects and for the overall viability of an organization are identical to the interest of a project scheduler responsible for bringing several projects on time and on budget. This means that whatever presentations, reports, analyses, meetings and so on, must be tailored to who is involved. I’ve done hundreds of presentations on our own project control timesheet software and almost always have someone from the executive level of the firm in attendance. But I almost never have that person attend the entire presentation. We organize the agenda and schedule of the presentation so that the executives can attend the section most appropriate to them and leave if they wish (They almost always do) before starting the “nuts and bolts” of how the software works. Executive briefings almost never last more than an hour.
• · Next, organize regular project management reports and presentations for management with the knowledge that there will be never be an understanding of the arcane terms and science of project scheduling and project cost control. Remove references to such items from your reports. If your project management software is incapable of doing things like renaming terms like “Late Start” to “Projected Finish”, start thinking about new software. In this case, less really is more. Keep your reports to a page or less and, if you must, keep a 2^nd level detail in reserve to back up your analysis.
• · Third, apply project management principles to your project of selling project management to management. Can I say this enough? The most infrequent users of project management are project managers on their own projects! How does this apply here? It doesn’t take much imagination. Define clear goals, get a project sponsor, set a timetable…you know the rest.
• · Don’t be enthralled by the notion that the purchase of any one piece of software will instantly and completely solve all of your project management problems. The implementation of software is sometimes a perfect time to effect a culture change. Sneaking in a new paradigm of behaviour on the back of a project control system is a favourite technique of mine.

You’ve got to look at the whole project control process whenever you’re interested in improving the effectiveness of project management. If you’re interested in selling project management to your own management, start with identifying management’s role in the process. Where do they fit, what is their contribution and what impact will that contribution make to the enterprise? A request for input when that input will clearly make a direct difference to the outcome of something is irresistible to almost everyone.

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.

Written originally in the tech crash that followed Y2K, this article describes many of the challenges and opportunities facing the project management industry in today’s economy.  The article is reposted here from its original publication in Computing Canada Magazine.

If you’re in the high-tech industry you know we’re in the middle of the largest reorganization of the industry since its inception. For years, we’ve seen waves of growth in the computing field but this is the first time ever that the pace of growth has slowed. You can argue that we’re in a temporary “correction” or a long term readjustment of growth but either way the playing field has changed.

Last year while the high-tech stocks were flying we saw a newfound interest in IT operations becoming more effective. No surprise, many of us in the industry were finding resources difficult to find and the results required by the market in terms of completed projects more plentiful. According to Admiral Ken Mattingly (You may remember him from Apollo 13 fame), “A project is an undertaking to produce a result with limited resources within a specific time”. Sound familiar?

Yes, while much of the economy is struggling with avoiding a recession, project management is on a tear. It was the same in the early 80’s when our firm got started. We were a couple of young upstart consultants who specialized in automating project management environments. It would not be until years later that we would realize how timely our entry to the industry would be. The recession of the early 80’s was very difficult for many firms but not for ours. The difficult business environment was tailor made for us to be successful. Whenever there are difficult economic times, project management leaps to the fore. It makes sense. The science of managing projects is done, after all, in order to be more efficient at producing a result. The objective is to produce more results (e.g. more projects) with the same resources or the same results with less resources (e.g. less people and money and time). Again this sounds very familiar to today’s scenarios for people in the IT field.

If you’re in a struggling dot.com then revenue growth at any cost is no longer your goal. You’re now being pressed to deliver similar results but with less cost. If you’re in a more established organization (did someone mention Telcos?) Then you’re in a squeeze too. You may have just arrived at work to find that you’re one of the lucky ones, left behind after a huge reduction in force. That means you’ll be asked to produce the same or similar results as the company has been producing only with much fewer staff.

This is a perfect call for project management.

Happily, IT has already had a big introduction to project management through the frenzy of the Y2K phenomenon. Project managers were squeezed to produce results then too but the limited resource in 1999 was time, not people or money. Still, the exercise is the same and many IT firms that I meet have been clever enough to retain an d even enhance their project management skills in the intervening time.

No matter which way you turn, if business is tight, then project management is a good choice. The benefits for firms in this situation are numerous.

• First of all, if money and time and people are restricted, then managing by result (i.e. by project) is essential. The company will be successful or not based on the projects you can complete. In the IT industry, this may be directly tied to revenue that arrives from projects that are completed. To manage by department or to just manage by guesswork and good intentions is insufficient. Managing by project will allow ineffective projects to be quickly identified and allow management the oversight to make changes when required or to provide additional support when it will make a difference.
• Once you’ve got your project management system going, you can get an almost immediate return by being able to simulate “What If” scenarios to assess the impact of different events. Without a centralized project system, you have no way of returning to management to ask for additional resources, to suggest that a project should be lowered in priority or to renegotiate deadlines
• Next, if you’ve got an established project management environment, you can get one of the biggest benefits of all; being able to assess which projects are best for your organization to take on. In the absence of a good project management system, management or marketing makes decisions about what projects should be undertaken and when they are required. If they had the analysis available from a project management system, they might find that some projects are unfeasible because they will take too long, cost too much or (most likely) will tie up key skilled resources that are already committed to other work.
• Finally, if you are facing the worst case scenario and some of your project people must be let go, then a resource-leveled project management system will enable you to determine the impact of any resources that must be cut. You can analyze resource loading from various perspectives. What would be the impact on projects of proposed cuts? What cuts would result in the least impact or what cuts would result in the impact to the least revenue-generating projects. The results of such analysis are simply not available to organizations that have not implemented project management.

Ten years ago, project management was virtually unknown in the IT industry but that’s not the case anymore. If you’re finding yourself under pressure to perform at the moment, then look to your project management group. They can’t reverse the economy on their own but they can mitigate potential damage from cuts or reductions in resources and may well spell the difference between those IT companies that survive or fail in the new economy that will emerge from the heyday of the 90’s.

It’s a six-syllable word, I know. It’s this week’s topic of conversation however, thanks to a recent decision by the FASB. The Financial Accounting Standards Board is not the most reckless association on the planet yet we owe many of our own Canadian Generally Accepted Accounting Principles to their initiatives. They are the US Federal group of accountants who set accounting standards for companies all over the US. In June, the FASB decreed that intangible assets must be identified during the purchase of a company.

This category of assets has always been referred to as goodwill. With the shakeup of the technical sector this year, goodwill has become something that we’re all a little too familiar with. Goodwill is the difference between what the company’s financial balance sheet says the company is worth and what was actually paid for the company.

How is this possible you ask? Well, imagine a 10-year-old software company. It has 50 people in it and has grown through its own efforts, expanding by immediately reinvesting its own profits in its own growth. The company has done this by creating and the successfully selling 2 or 3 vertical market software products. Yet, when we look at the financial statements for this company, it might not look like it’s worth anything. The expenses for the firm have risen at the same pace as the revenues, eating profits for new staff, new equipment, new marketing efforts as the money became available. The company may have some money in the bank but the true assets of the company can’t be found in the financial statements. The valuable assets are the knowledge of the staff, the ongoing nature of the revenue stream, brand recognition, the client base and, of course, the software products themselves.

So why should anyone care? Well, in a technically oriented company, what is usually being paid for is knowledge. It’s been awhile since we spoke in any good terms about the movement to a knowledge-based economy but the FASB decision is, in my opinion a welcome one for the technical sector.

With all the mergers and acquisitions done in the past 2 years goodwill was the majority of what was traded. Companies were valuated at huge numbers not based on their balance sheet but rather a series of nebulous factors that no one felt compelled to identify. Being “first-out” carried huge advantages to valuation (ask pets.com) and the existence of growth meant that we could ignore profits for the foreseeable future (remember Amazon?).

There was, no doubt plenty of conversation and speculation about the intangible values in the cigar-smoke-filled back rooms where deals were made but no specific accounting of the value was ever required when the deal was done.

The FASB decision sets a trend for everyone in this industry. Now, the value of some of these intangibles will have to be identified. In particular the knowledge-base areas of the company to be acquired will have to be quantified in some way.

So, how do you go about valuating the efforts involved in high-tech? Any business owner who has been involved in a financing deal in Canada in the last 5 years can wince at this conversation. Financiers are in the business of buying low and selling high so they’ll point first to the book value of the company which almost always small. Software publishers generally take the opposite view. After all, they probably wouldn’t have started development on the products they’ve created if they hadn’t thought the result would be tremendously valuable to the market. Even if those products haven’t yet been released to the market and haven’t generated any revenue at all, they will perceive them as very valuable.

The truth lies somewhere in between of course. There are a few factors to consider for software and other high-tech manufacturers. Let’s tackle the easy one first; the commercial aspect. The revenue stream itself including existing and repeating clients is obviously key. It’s also not too difficult to identify the marketing expenses associated with a particular product line and most selling organizations have good records of the selling costs thanks to commission and sales bonus structures. These costs can help identify how much effort and money would be required to duplicate the results of the firm, a good indication of the value of what is being purchased.

Brand recognition may be important also. There are several accepted method of valuating a brand name but all of them involve some subjectivity. Trademarks is one of the areas to look at here, particularly registered trademarks and website addresses.

Next, however, is what should be the easiest and is often the toughest aspect of valuating technical efforts: the costs. First of all, there is the direct effort that was required to produce the product or products in question. This is often a labour oriented conversation but it might become critical down the line if you can’t identify what the relative labour involved in producing and selling a product was if it becomes very successful and a key element in a company purchase. Bear in mind that if you are on version 5, then the efforts to create versions 1 through 4 are relevant also (Taking into account some appreciation as you would do with any asset). A project-based corporate timesheet system may allow you to track these efforts task-by-task.

The R&D tax claim that many Canadian companies file each year is another method of quantifying the value of the research undertaken as part of any commercial effort but this also will require a task-by-task accounting.

Next, the value of the knowledge itself is critical to the valuation. Are there unique algorithms or methods of implementing the product line that can’t be replicated elsewhere? Valuating this is difficult but one way of doing it would be to estimate how much effort it would take a competitor to duplicate the efforts. Patents may be one of the methods of quantifying uniqueness here.

When you start thinking like this, you start looking at your business in a whole new light and I think that’s the point the FASB wanted to get across. You start looking at the knowledge base you’ve built up as though it’s an asset. Are you protecting that asset as well as, say the furniture in your office? Your furniture is probably insured and may even be protected behind an alarm system. Is it the same for your much more valuable knowledge? Are you backing up critical information off-site? (Not just your source code.) Are your employment agreements ensuring that employees cannot redistribute the critical information from that knowledge base to competitors upon their departure? Are you copyrighting your software code or applying for patents for firmware or hardware innovation?

The FASB is an American institution but thinking of the value of the knowledge in your own organization is universal.

I had the privilege of speaking to a group of project managers recently and the hot topic of the evening was the trend towards new “collaborative” project management tools. It’s true that “Collaboration” has become the latest buzzword in a sea of project management software vendors as they try to distinguish their products from amongst all the others.

Collaborative project management – it sounds like a great new process. After all, who could possibly argue against a collaborative process? The answer, of course, is no one. Project management by its very nature is a collaborative process. I’d sure like to see some pm software that is non-collaborative. If you’re not collaborating with someone, then you’re probably not doing much project management. Nonetheless, collaborative project management software is all the rage and from my many visits into the head offices of corporate culture I can understand why.

There is an almost universal problem I encounter when talking about project management; a problem to which almost all executives I come into contact with are intent of finding a solution for. The universal desire is for a cross-project, enterprise-wide resource capacity planning system. At one time this kind of functionality was not critical in a project management system. Project management software as usually applied only to a mega project where enterprise project management meant managing one project only. On mega projects, resources are often considered to have unlimited availability. Schedule is the critical factor. There are still pm environments like this but they are much rarer than they once were.

The most common project environment today involves many projects, all competing for a small number of highly skilled resources. Line managers, department managers or resource managers often control those resources. The projects themselves are managed by project managers who must assemble their project teams in an environment where they must compete against other project managers vying for the same people. This is the classic matrix environment and it is as common as can be in business today.

The structural tension between the needs of managing the employees and the needs of the projects to get completed is supposed to deliver a compromise which affords the best to everyone but it doesn’t always work out.

The problem is the human factor which is rarely considered when creating such an environment.

This week I had occasion to see this in action at one of our country’s larger telecommunications companies. (No, I won’t embarrass them by saying who it is.) I had been called in because management at this firm had determined that it had no visibility over the capacity of the organization to take on new projects and to model the impact of new initiatives as they occurred. It’s not a new request; I get it several times a week so I was well prepared to discuss the problem. I met with a selection committee who had been given a mandate to find a software solution to the problem. Would I update them, they asked on the ability of different collaborative project management software systems to perform multi-project resource analysis, capacity planning and what-if modeling ? Of course I would but my first question was to how they were operating now. Oh no, I was told, the existing system was completely insufficient for their needs. Well that wasn’t my question. It took some teasing (it always does) but finally they confessed that although multiple project management systems were in place, no two project managers worked together.

For those of you thinking I must be speaking about you organization, take heart. The good news is you’re not alone. The bad news? You have plenty of company.

This scenario is amazingly common. It’s true that my sample of data is badly skewed since the people who call me mostly have a problem they are trying to solve. Those who have great solutions don’t seem to look for my advice. Still, what amazes me is how a group of what seem like highly intelligent people can have the notion that the implementation of software will make project managers collaborate.

For this organization who seems intent on breaking out of the mold that they’re in, there is certainly hope but my comments to them involved very little talk about how features worked and a lot of conversation about how they will need to change the culture if they are to have any hope of success.

“Can’t we just have a multi-project resource leveling?” they asked. “Sure,” I said. “Please point to the person who will be setting the project priorities so that projects can be analyzed together without making a low-priority maintenance project get resources ahead of a company-critical development project.”

Hands were slow to rise. I can understand why. This will not be a job to be envied the first day that someone’s project has resources removed from it so that a higher priority project can move forward. Would someone be ready to sacrifice the productivity of their own project for the greater good of the organization? Would they give access to the resource records under their control with the risk that they be co-opted by someone else?

There was, I think, some misguided hope that the software would tackle that decision for them.

The great Diaspora of computing that started with the PC is coming back to haunt us. We’ve all become a little spoiled at managing our own data in our own world. The advent of centralized networked data is pushing some of back together in functions like project management. With the Internet making the technology of sharing data easier and web-based architecture pushing data back into a centrally managed source (onto a client-server database instead of in Excel on my hard disk), some of us are being asked to share; something we haven’t really had to do for a long time. Our notion of sharing has been coloured by an entire generation of PC users who say “well you share everything you’ve got with me and I’ll think about whether or not to share anything with you.” Centralized project management doesn’t work that way. It’s true that technology now provides us the opportunity to automate a collaborative project management practice but is our do-it-yourself generation ready to truly share? It was something I threw out to this group of project managers at the telecommunications company.

There is no doubt that everyone in the room desired a solution but I challenged them to deal with the corporate culture that caused the problem. Would they be able to collaborate given the chance? The jury is out.

I’ve been very encouraged in recent months at all the organizations that I’ve come into contact with that are making a real attempt at multi-project management.  It’s no surprise that enterprise-wide project management is a hot button right now.  The economy is tight and virtually everyone is trying to do more with less.  Also, the nature of business these days is that multiple projects are the norm rather than the exception.  With resources being commonly restricted (I mean no one has a complete spare project team just standing by in their offices, waiting for you to pick a project so they can start doing something), enterprise resource capacity planning has become the universal holy grail.

Despite these significant efforts in many major companies around the world, I’ve been asked more and more lately how to handle one of the most delicate aspects of multi-project management: prioritizing the projects.

In a lecture I gave recently I was speaking about the challenges of creating a centralized project management office only to be stopped cold by a comment from the floor.  “We’ve done all that,” said one CIO of a large Canadian company you’d recognize if I mentioned it.  “We’ve successfully created an enterprise project environment, loaded the data and now have produced enterprise resource-capacity planning reports for 3 months.  The challenge we have is that when we send the list of projects to management to prioritize, they all come back ‘Priority 1’”.

He’s not alone.  In working with companies from all over the world this year, I hear this comment has become all too frequently.  Is it surprising?  Not really.

There are several issues with this aspect of enterprise project management.  First of all, who wants to have the job of informing a senior manager that their project has now been designated as a lower priority?  Not me.  Not anyone, really.  So, as a consequence, when the issue comes up, there are few volunteers in the project team keen to tackle the challenge with management.  It’s easier in some ways just to keep going.

Next, there are plenty of disincentives for management to not elect their project to be anything but the highest priority.  Just like the challenge for project managers who contend for resources, the person who says their project is anything but the top priority is guaranteeing it will be delayed or even late.

When there’s a client involved, the conversation is even lest attractive.  Now, selecting a project for a drop in priority means contacting the client and dealing with a delay.  The impact may have legal implications and who wants to be bearer of that news?

Marketing will have a hand in things too in many organizations.  There is nothing with such high priority as your next client and a project for tomorrow’s client always seems more important to marketing than yesterday’s news.

When project managers go to management with their corporate-wide data and explain that there are only so many factors to manage and either the amount of work, the number of resources or the schedule has to give, the most common response is: “Well, we can’t hire staff – hiring freeze.  We can’t delay the schedules, everyone is counting on us to deliver on time and we can’t change the workload, those are our contracts.  You’ll just have to have your people work harder.”

For some managers, no presentation of empirical data seems to make any difference.  The consequence is that all projects are rated highest priority and everyone suffers.

Is there a solution?  Of course.  The secret to implementing culture change at this high a level of the organization is to be patient.  Starting with presenting some VP a list of projects and a red pencil isn’t going to be productive.  A better place to start is by outlining the problem to management without asking at first for a solution.  By highlighting the lack of project prioritization and the resources now being spent on what must be low-priority tasks, you may find a friendlier face for accepting an enterprise system in the first place.  Then, while working on the implementation of an enterprise system, start working on training exectuvies in the prioritization process.  Expect that in most cases, it won’t be complete in a couple of hours.

A skilled project manager will be able to paint a picture for management which first of all, shows that not making a priority decision is, in fact, a decision.  Also, the theoretical impact of project prioritization can be made to look very attractive.  Just about every project management software vendor has a demonstration which shows the impact of multi-project prioritization – it’s a key selling features for almost everyone.  This kind of demonstration can be part of your executive training and key to making the point that sooner or later, someone will have to deal with this decision.

Once you’ve got the ball rolling, implementing a new process without looking at real data is probably easier.  You’ll need to deal with ho to assess a project and some measures for setting a project priority which is just a subjective feeling.

Some key indicators for each project, which you might consider in your own process, are: the length of time project has already been underway; the amount of money spent on the project to date; the project performance in terms of cost and schedule variance; project return on investment to the organization once the project is complete; legal implications of delay; categorizing work into bill-for and internal; risk assessment of the ongoing project work and; the impact on other projects. 

Get the process documented and get the various managers to agree to it altogether.  It’s important to get agreement across the board because if one senior executive won’t play, then the incentive for everyone else to do the same will become astronomical.  There’s still going to have to some handholding when you get that first enterprise project list to deal with, but at least you’ll have paved the way.  If you can get buy-in for the basic process from senior management, you’re well on your way for that final stage in enterprise project management.  If not, you’ll still get benefits but the primary purpose of the system is likely to be thwarted.

I’ve had the opportunity lately to do some actual in-the-field consulting, something I thoroughly enjoy.  This year I’ve been able to work with quite a number of clients on a much broader-based enterprise-wide project management environment.

It brings me back to my roots but I’ve also come across a phenomena that is very new to me but that I would have never predicted 25 years ago as I was getting into the project management software industry.  As we’ve worked on all the aspects of implementing a corporate-wide project management system lately, a surprising obstacle has been the professional-level full-time project planners. 

This is a bit of a shock for me since these are the people who I know best.  In the early 80’s when companies were moving from mainframe-based project systems down to PC-based systems and companies who could have never afforded a mainframe system were looking at project management software for the first time, full time project managers and project planners were our client.  They had the knowledge and skill required to take project data and move it into a project management system.  These people were usually co-located in a project management office of some kind.  When it came to establishing a corporate process that includes project management, the professional project managers were always involved.  They were, after all, the very kind of people who had helped develop standards like the Project Management Institute’s “PM Body of Knowledge” (PMBOK).

So, why on earth would I consider anyone in this category as an obstacle?  These are often the same people who are the driving force behind a movement to enterprise-wide project management.

The problem stems from the very thing that makes these people such a key resource – their experience.  Professional Planner have, almost by definition, been at this for a long time.  They’ve had to invent, establish and maintain project standards even when no one else in the company was interested.  When projects had to be managed, these people had to do so centrally.  The idea of an enterprise-wide project management system was very attractive to them – almost a holy grail of sorts.  The idea was that individuals would be able to access a central system and update it with all manner of data in a variety of categories.  Having access to this data in a more timely and (more importantly) easier to gather manner was highly desirable. 

Ok, now fast forward to today.  Project Management has entered the lexicon of every business school in the world.  If you have no understanding of project management as a manager, you’re in big trouble.  The old-school planners should be tickled – right?  Well, no.  They have suffered an increasing irritation of people entering their domain who don’t think of projects the same way.  The ERP contingent has been thinking of projects from a primarily corporate financial perspective!  The desktop planning contingent (can you spell Microsoft?) have permeated the market with easy to use planning software so easy to get going that anyone who can type with one finger can generate a professional-looking schedule.  To these people anything is a project!  The IT people have even taken an interest in the subject, daring to think of themselves as project managers.  Terrible!

So, now management expresses a desire to move to enterprise-wide project management as a discipline.  The old-school professional planners are, of course, included in the conversation because they know more about project management methodology than anyone.  I get called because of our long-standing experience with implementing enterprise project management and, guess what?  The pro’s are finding themselves not in charge of the implementation but only one of several categories of users in the conversation.  They have become the clients rather than the internal consultants. 

It’s natural, of course, if you want to work across the entire enterprise, you can no longer think of only the professionals, the one of a thousand people who use project software 8 hours a day.  You must think of everyone involved in the project management process.  This includes the professionals, of course.  But it also includes executives, resource managers, team members, even clients, sponsors, suppliers or anyone else who forms a part of the project.  When you really think of the implications of implementing across the entire enterprise, you’ve got to think of everyone.

When you’re implementing coordinated project management across the entire enterprise, everyone involved wants to ensure that they’re particular concerns are met.  The team members who might use the system only a few minutes a day want to be sure it’s not a burden and not too complicated.  The pro’s want to know they can get access to the data and perform all manners of analysis.  The executives want access to better decision-making.  Resource managers need to know they can see the load on their people and forecast future requirement adequately.  Finally, the IT department (aside from their own project management requests of course) need to make sure that whatever is implemented will not require excessive support or be too much of a burden on the network.

To make this work, virtually everyone will have to compromise a little.  Just getting along with everyone else is often a challenge, never mind having to find a common way of working on something as critical as project management.  Yes, sadly, that means everyone – including the professional project managers.  They may find some of the analysis that was so important to them when they worked alone something that they need to sacrifice.  I was debating this with someone recently.  “How will the resource algorithm work in this particular tool?” She asked.   My response surprised her. “What difference does it make?” I said.  “If you can get all the project data into one place, managed by one system, reported on together, you’ll be so far ahead of what you’re doing now that the analysis you’re speaking of will pale in comparison.”

It brings me back to the fundamental challenge in any enterprise project management implementation and that’s compliance.  The tools, process, strategy and culture have all got to promote working together or none of the technology will have the chance to make any difference.

I’ve been in a lot of corporate meetings lately discussing various aspects of delivering an “integrated” project management environment.  Don’t get me wrong, a corporate-wide integrated system is a wonderful thing to desire.  There’s no doubt that the idea of pushing a button on a screen and finding that every element of data across the company is tied to every other element in just such a way that the answers I desire are immediately available in every detail seems fabulous.

The delivery of such wonders, however, usually requires a little more thinking.  As you might imagine in the project management world, it is often a combination of tools that deliver the total functionality desired.  I know, I know.  Many ERP vendors have done a fine job not only in selling the idea that one tool delivers all solutions but in advancing their solutions to have their software actually do so.  The problem comes when deployment starts and in the field we discover a need for other tools to become a part of the “integrated” solution.  Often a scheduling tool such as Microsoft Project or Primavera will be part of the conversation; sometimes it’s a specialized tool for managing costs or risk or issue tracking. 

In every one of the cases I’ve come across in the past few months, all the vendors involved have been quick to point out how their tools are linked to whatever ERP or Finance system is in question.  Unfortunately it’s not always so easy.  Everyone is telling the truth of course.  The links being described or even demonstrated do work.  The issue is that they work in the demonstrations based on a range of assumptions that are not always made clear. 

It’s a truism that systems can only integrate at the lowest common denominator, but for some reason, that is not obvious to everyone who works on integration projects.  Recently, for example, I was asked to describe how the data from a high-level costing module of an ERP would move its data to the more detailed database of the scheduling tool.  The tools had been selected long ago and there was no problem with either.  During the deployment, the Finance group had worked on the configuration and deployment of the ERP system and the Project group had worked on their scheduling tool.  The decisions of each group on the configuration of the data were valid and justified.  The problem was, they weren’t coordinated.

For the desired system to work, the company would have had to managed data in the ERP at the same level that scheduling was doing.  This involved tens of thousands of tasks and hundreds of projects.  In theory, Finances system had the capacity.  In practice, it was unwilling to manage at that level of detail.  The result?  Data could be consolidated and rolled up from the project system but could not be “de-constructed” and moved down from Finance. 

For any integrated implementation it’s crucial to look at how systems and their data must be configured in order to integrate at a later date.  There are often trade-offs and compromises to make that are easier to do the earlier you make them.  Remember, just knowing that a link between systems exists makes systems integrateable.  It doesn’t mean yours are going to integrate unless you follow all the unspoken assumptions.