Skip to main content

Commoditizing Project Management for the Mid-market

Written by Mike Morton on . Posted in Articles. 3 Comments on Commoditizing Project Management for the Mid-market

Over the last five 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 that 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 administrators and programmers, and so on.

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 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 that 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 level 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 five 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.

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!

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 sometimes hear people 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.

Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at [email protected]

Adding Manpower to a Late Software Project Makes it Later

Written by Mike Morton on . Posted in Articles. 3 Comments on Adding Manpower to a Late Software Project Makes it Later

In 1975 a mighty clue bat was unleashed on the software world. In The Mythical Man-Month, Fred Brooks reminded us there are finite limits to our ability to compress the development process. Moreover, throwing people onto troubled projects often backfires. These insights should not have surprised us; after all, time and effort are hardly fungible commodities. Even with the best tools and methods, nine women still can’t deliver a baby in one month.



If Brooks merely reminded people of what they already suspected, why do so many software projects still come in late and over budget? A recent study of the QSM database showed that large projects (defined as over 50,000 ESLOC) have only a 19% chance of meeting their planned schedules and a 30% probability of making their budgeted effort. It’s discouraging to see organizations struggling after thirty years of technological change and process improvement effort. Why does this still happen so frequently? More importantly, what can we do to change it?

Technology Advances, But People Remain All Too Human

Part of the problem is that while technology has changed rapidly, human nature remains constant. A critical ingredient in software development – perhaps the critical ingredient – is people. This is an insight technical managers sometimes forget to factor into their plans.

Tools and methods allow us to do things more efficiently, but software development remains a uniquely human endeavor. Consequently, successful project management requires a mastery of both people and technical skills. The first part of this paper deals with the human factors that trip up so many software projects. The latter part brings data to the problem-solving table.

The people problems that plague software teams tend to involve over-optimism, fear of measurement, and using the wrong tools for the job. They fall into three broad categories:

The Triumph of Hope over Experience:

  • Competitive pressure. Bid solicitation (especially in the outsourcing world) involves a great deal of internal pressure on participants to win business. This competitive ‘tunnel vision’ often leads to overly optimistic assumptions that ignore an organization’s proven ability to deliver software.
  • Unfounded productivity assumptions. If it has always taken 20 hours to produce a widget, assembling a crack team of developers will not cut that number to 10. Productivity improvement is a long-term endeavor; not a short-term fix.


Fear of Measurement:

  • Not learning from history. Companies which measure projects well, develop organizational self-knowledge, identify capacities and patterns, and come to know their strengths and weaknesses. In short, they learn from experience and develop an empirical basis for project planning. Unfortunately, most organizations lack formal software measurement and evaluation capacity or measure and plan haphazardly. Lacking self-knowledge, these organizations continually put themselves at risk.
  • Not planning for growth. The planned project generally differs from the delivered project in one key component: it is smaller and delivers less functionality. Good project management and effective change control help mitigate scope creep, but a recent QSM study showed a median size growth of about 20%. Projects locked into budgets and schedules based on one set of requirements will be sorely pressed to meet these commitments when the requirements increase.
  • Not watching where we’re going. Most software teams work hard and want to succeed. There is an admirable human tendency to double one’s efforts when problems arise. Such industry should be encouraged, but Herculean effort makes a poor substitute for timely, gentle course corrections. In fact, it is usually too late to take effective countermeasures when problems finally manifest themselves.


Applying the Wrong BandAid:

  • Ineffective or inappropriate countermeasures. There are only three possible courses of action when a project threatens to exceed budget or schedule. Each works within a limited range of possibility and carries accompanying cost.
    • Relaxing the schedule: Results in a less expensive project with fewer defects. There are good and bad reasons why this option is not used more often. Legal or contractual requirements may mandate delivery by a certain date; late delivery may invoke penalties or loss of customer goodwill. Also, organizations may have committed project staff to other endeavors. The bad reasons center more on reluctance to change and unwillingness to “lose face”.
    • Reduce the scope of the delivery. Deferring non-critical functionality until a later release (or eliminating it entirely) can keep a project within time and cost constraints. The cost is obvious: less is delivered than was promised or expected.
    • Add staff. Within a narrow range, adding staff can reduce schedule, albeit slightly and at considerable cost. As many managers have discovered, schedule/effort tradeoff is non-linear: a single unit of schedule reduction “costs” many units of effort and this ratio increases exponentially as the schedule is compressed.

Challenging the Conventional Wisdom

So, what are harried software managers to do when faced with non-linear relationships between time and effort, technology that changes constantly, and human behaviors that, despite experience, remain stubbornly entrenched? This is where measurement is invaluable. Having a good metrics program in place tells organizations several important things: what they have built in the past, what their historical capabilities are, and which patterns in the data may be helpful in the future. A good metrics program does one more thing: armed with a good historical baseline, managers can monitor their progress and make timely course corrections as projects unfold. For managers who need to assess the risks/benefits of using new technologies in real time, this kind of feedback is priceless.

As technology continues to shift the productivity curve outward, managers are tempted to challenge the conventional wisdom. The allure of Agile programming may make them wonder if it isn’t possible, after all, to make that baby in one month instead of nine. This is not necessarily a bad thing. As new tools and methods appear it makes sense to reexamine old assumptions about the relationships between time, effort, and productivity. But that reexamination should be grounded in empirical methods and hard data, not pie in the sky optimism.

Take Fred Brooks’ famous maxim,“Adding manpower to a late software project makes it later”. QSM researchers have found a strong correlation between project size and most other metrics. In our experience, the non-linear relationships between size, time, effort, and defects often make simple rules of thumb less than universally applicable. In practice, these tried-and-truisms often hold true for many, if not most projects but since many software relationships ‘go exponential’ at certain points along the size spectrum, it’s probably not a bad idea to test them against the data.

“Adding Manpower to a Late Project Makes It ????”

We looked at large Information Technology software projects completed in the last decade to answer the question, “Just how does the ‘mega staff’ strategy affect large projects?” On a scatter plot of effective (new and modified) size vs. average staff we found an interesting separation in projects at the high end of the staffing curve. We call this gap the “Unglued Point”: where staffing runs wild.

Below 100,000 lines of code, the projects are evenly distributed. But beginning at the 100 K ESLOC mark, a hole opens up, separating the bulk of these projects from those staffed at far higher levels.

The trend lines in the first chart are average, plus, and minus one standard deviation lines. At any point on the size spectrum, there is wide range of staffing strategies. Above the range of ‘normal’ variability is the unglued point, representing projects with exceptionally high staffing. The high staff projects position well above the +1 standard deviation line, placing them over the 68th percentile, closer to the 75th percentile or above.

What can these high staff projects tell us? How do their schedules compare with other, more reasonably staffed projects? How does the high staff strategy impact project quality? And of course, what are the cost implications of such a strategy?

Let’s find out.

The second graph displays only projects above the unglued point for staffing. The parallel lines show average, plus and minus 1 σ trend lines for “reasonably staffed” projects. Crossing these diagonally is the trend from the high-staffed projects shown. For projects up to 100,000 lines of code, using large teams seems to deliver projects at or below the QSM average for schedule.

However, matters deteriorate rapidly as projects increase in size. At best, aggressive staffing may keep a project’s schedule within the normal range of variability but this strategy becomes increasingly ineffective as project size increases.

What about quality? Again, only high staff projects are shown. The steeply sloped line crossing the QSM defect trend lines is the average of the mega-staffed projects. Their quality is consistently worse than average (higher defect density) and increases precipitously as the projects increase in size. The impact of high staffing on project quality is clearly negative.

Finally, what are the cost implications of the large team strategy? First let’s review what is purchased in terms of schedule reduction: at best high staffing moves a project into the range of normal schedule variation, though this strategy becomes increasingly ineffective as projects increase in size. Overall project quality, which is its legacy to its users, is worse than normal. Now the cost: as the following table illustrates, high staffed projects are several times more expensive.

As to the question at the start of this section: If you answered ‘later,’ you were correct.

Conclusion

So, how did Brooks’ famous maxim hold up against the evidence? Does adding staff to a late project only make it later? It’s hard to tell. Large team projects, on the whole, did not take notably longer than average. For small projects the strategy had some benefit, keeping deliveries at or below the industry average, but this advantage disappeared at the 100,000 line of code mark. At best, aggressive staffing may keep a project’s schedule within the normal range of variability.

Contrary to Brooks’ law, for large projects the more dramatic impacts of bulking up on staff showed up in quality and cost. Software systems developed using large teams had more defects than average, which would adversely affect customer satisfaction and, perhaps repeat business. The cost was anywhere from 3 times greater than average for a 50,000 line of code system up to almost 8 times as large for a 1 million line of code system. Overall, mega-staffing a project is a strategy with few tangible benefits, which should be avoided unless you have a gun pointed at your head. One suspects some of these projects found themselves in that situation: between a rock and a hard place.

How do managers avoid these types of scenarios? Software development remains a tricky blend of people and technical skills, but having solid data at your fingertips and challenging the conventional wisdom wisely can help you avoid costly mistakes. Measurement allows you to manage both the technical and people challenges of software development with confidence whether you are negotiating achievable schedules based on your proven ability to deliver software, finding the optimal team size for that new project, planning for requirements growth, tracking your progress, or making timely mid-course corrections. You might even avoid that giant clue bat!

 

 

Kate Armel is a technical manager with Quantitative Software Management, Inc. She has 8 years of experience in technical writing, metrics research and analysis, and assisting Fortune 1000 firms estimate, track, and benchmark software projects. Ms. Armel was the chief editor and co-author of the QSM Software Almanac.

Donald M. Beckett is a consultant for Quantitative Software Management with more than 20 years of software development experience, including 10 years specifically dedicated to software metrics and estimating. Beckett is a Certified Function Point Specialist with the International Function Point Users Group and has trained over 300 persons in function point analysis in Europe, North America, and Latin America. He was a contributing author to “IT Measurement: Practical Advice from the Experts.” Beckett is a graduate of Tulane University.

Project Manager Perspective

Written by Mike Morton on . Posted in Articles. 3 Comments on Project Manager Perspective

In the last few months I’ve had occasion to come across some project management difficulties that have everything to do with perspective.  We rarely consider the point from which we create our point of view because we live inside it.  Our perspective is often how water is to a fish.  We swim through it all day but never really notice or declare it’s there.  Yet not acknowledging that our point of view is really coming from our perspective can cause tremendous difficulties in a project and opens a massive blind spot.

 

Why does this matter?  Because no two people have the same point of view.  When you think of looking at something, you can get right next to someone and see things from almost their perspective, but it’s not exactly the same.  Their head would have to be displaced for you to see things from where they were.  Yet, if we do just that, move their head and move your eyes to the exact spot they were in, it’s already a different time.  Time counts too in a perspective.  So if we can never see things exactly the way someone else sees them, how do we communicate effectively at all?  We can allow for a perspective by declaring our point of view. 

 

In the absence of realizing that everything we perceive comes from our own particular point of view and that our perspective is unique, people are left with saying “that’s the way it is” rather than “that’s the I see it”.  Is this just semantics?  It very definitely is not.  If you say “that’s the way it is,” then it allows for no other interpretations.  You’ve declared that the universe is that way, there is no other and that’s the end of the discussion.  If, however, you say, “that’s the way I see it” you’ve made room for at least one other perspective.  Someone can now say “I see it somewhat differently”.  When this happens, you may be surprised.  ‘How could someone interpret this differently?’ you may ask yourself.  Your eyes suddenly open as you realize that perhaps there are yet other interpretations that you’ve not considered.

 

In the world of project management, being able to identify a perspective as a perspective is a critical skill.  In any project, schedules and scope are often identified by the shortest of descriptions.  Four or five words in a schedule may be all the description of scope that a task has.  This isn’t any problem if everyone understands the same thing by those four or five words but that’s rarely common.

 

Much more likely is that everyone who reads those four or five words has interpreted them differently. 

 

“Write process documentation” is a description I saw recently in a project in which we were involved. 

  • The new consultant read these three words and imagined a document that would be two or three pages in length. A title and sentence for each element of the process would be plenty, he figured. A total of four hours would be sufficient to the task, he thought.
  • The project manager envisioned a document of 20 or 30 pages. A page per process would be required and a flow diagram of each process would headline each page. The document would have to go to internal review after one draft and then client review after a second. The work would take about 10 days.
  • The client envisioned a manual of about 200 pages. Each process would be a chapter. The flow diagram would headline the chapter, there would be a brief synopsis and then the process would be described in a step-by-step fashion complete with screen shots using their own data. The client expected that this manual would be done naturally as the project evolved, with a new chapter added as each process was created. They saw a review period of 10 days as about right for reviewing the manual once completed.

 

Needless to say when the documentation was written, everyone was upset.  When the project manager tried to describe what they had done, the client was shocked.  That wasn’t “proper” documentation,  the PM was told.  The consultant too was upset.  They’d figured the work they would have to do would be a short description.  They’d been obliged to go back to each process and design a flow diagram and a lot more detail. 

 

“Create a link from product A to product B” was a description we found in another project recently.  Despite the documentation that the client had seen, and a demonstration that they’d attended they were shocked to find out that the link created between the two products needed to be triggered by an action by a user.  ‘How could anyone call this a link if it wasn’t “automated”?’ they asked.  When it was pointed out that the client had both seen the link working and seen the feature description of this link, they explained that they’d assumed they weren’t seeing the whole picture because “of course” any link would be automated, wouldn’t it?

 

It’s about perspective.  Everything we’ve ever experienced adjusts our perspective and if you don’t at least acknowledge that there’s no such thing as an unbiased observer, then what you’re most likely to encounter are problems with scope and problems with estimates.

 

Project managers hold a pivotal position in the success of the project.  Regardless of the level of authority of a project manager, they are virtually always considered a facilitator for the communication between those who will do the work, those who will consume what is created and those who will manage the people and the work.  Communication skills are critical, of course.  But, in my opinion, an even more critical skill is being able to identify the point of view of each player in the puzzle.  This is partly why Collaboration has been identified as such an important aspect of Enterprise Project Management.

 

So, how do you mitigate the risks of an inadequate appreciation of perspective?  Start by working on your own perspective muscle.  Learn to challenge your own “isisms”.  When someone says “the way that it is, is…” challenge the assertion, even if it’s just to yourself.  If you catch yourself saying “that’s the way it is,” work on catching yourself.  A book that helped me in this area is from Edward de Bono and is called the Six Thinking Hats.  It’s a classic and is easy to find.  The book deals with how to generate creativity and perhaps that’s a good skill for project managers also.

 

If you’re looking for more practical techniques to avoid the kinds of examples we see above, take a page from the Defense and Aerospace folks.  Project managers who works in those environments have had requirements to include two documents that are essential parts of any mega-project bid.  They are the SOW (Statement of Work) and the BOE (Basis of Estimate).  They’re the bible for anyone doing project work in these environments, because they are a requirement and they identify in much more explicit detail what is meant by the short scope description that we’d normally see in a task name.

 

In the end, if you’re capable of at least identifying your own perspective when you describe something to someone else and acknowledging that they may have their own perspective, you’ll already be ahead of almost everyone.

 

 

Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at [email protected]

Communicating with “Non-Experts”: A Guide for Project Managers

Written by Mike Morton on . Posted in Articles. 3 Comments on Communicating with “Non-Experts”: A Guide for Project Managers

When you run a project you have two responsibilities: you must manage both your project and the organization’s relationship to your project. This second job is often more difficult. You are a technical expert, accustomed to working with other technical experts. Now you must influence non-experts – executives, end-users and others — who are in a position to help you or to hurt you. Welcome to the world of organizational politics.

 

Political problems trouble, delay, and sink projects more often than do technical problems.  Resources are diverted, requests go unanswered, specifications mysteriously change, and business units either ignore you or try to run things.  People expect the impossible and blame you for not delivering it.  People don’t listen and blame you for not telling them what was happening.  You must accept that communicating, selling, and persuading are basic organizational survival skills. Your success depends on engaging the interest and support of very bright people who know little about your area of expertise.  You must always remember that these “non-experts” will define your success or failure.

 

The label non-expert does not suggest stupidity or even lack of interest.  Expertise is different than intelligence: it requires massive amounts of information and years of training in working with that information. You are probably appallingly ignorant of marketing or finance or accounting or manufacturing or customer service. We are all non-experts most of the time.

Experts and non-experts think differently. Despite this, we typically try to use the same communication strategies with both. We provide expert information – details and methods – to non-experts and think we have communicated. We have not. We have spoken but no one is hearing.  Look at good popular science writers – like Matt Ridley or Timothy Ferris or Malcolm Gladwell. They focus on people, they give examples, and they tell stories. They understand non-experts.

 

Recent work in cognitive science has drawn a vivid picture of the non-expert. Outside our areas of expertise:

  • we don’t think abstractly – we think concretely, in pictures, in examples, in metaphors, and in stories;
  • we don’t think logically – we need help seeing how things connect and how one event is related to another; and
  • the personal dimension of communication becomes more important – because we can’t directly evaluate the evidence, trust in the messenger becomes crucial; we attend less to what experts say and more to how it is being said and who is saying it.

 

The less we know about any topic, the more powerfully simple images and stories shape our responses. You need to know the images people have of your project and the stories they are telling.  Are they saying it’s another self-indulgent engineering toy; another waste of the money the rest of us work so hard to make, another bleeding-edge effort?  You only have one tool here – get out in the business and listen.  Talk to people and ask direct questions. You need to know what people are already saying and hearing.  If you are telling a manager how helpful your new scheduling process will be and her best friend from college is telling her how something like this screwed up routing for three months in her company, you are in trouble.

 

Outside our expertise, we have difficulty seeing connections and implications. I was recently at a managers’ meeting in a major financial organization.  During a discussion of the largest systems project in the organization – a new accounts-receivable system – the marketing people volunteered that they were supporting the project even though it had nothing to do with them.  The systems people were aghast. The database capabilities of the new system, they asserted, meant that it would have more impact on marketing than on any other area of the business.  Now the marketing people were aghast; no one had mentioned this to them before.  The project’s natural – and powerful – allies had been ignored.

 

This brings us to the most important point: communication with non-experts is always personal. It is not about “the project.” It is about them and it is about you. These people know that they can’t evaluate the technical side of your project. What they think they can evaluate is you. They can decide whether or not they trust you. We all make these kinds of evaluations regularly with physicians, auto mechanics, and stockbrokers. We can look at the certificates on their walls, but in the end, we make a personal judgment.

 

Help people trust you. Your reputation in the organization is not built simply on the results you have obtained. Your reputation is based on people’s perceptions that you are helping them get what they want. What they want first is to know that you understand their problems. If they believe that you do, they are inclined to trust you. You become “one of us” rather than “one of them.” 

 

Two questions that are at the heart of any strategic communication: what do they want from you and what do you want from them?  Or, to put it more effectively, how can you best help them and how can they best help you?  For this, you need to know your different audiences because their hopes and fears are your real topic. Since one of the universal realities of organizational life is that these concerns differ at different levels, let’s distinguish your three key audiences: the leaders; the managers; and the users.

 

The leaders are your first audience.  Depending on the scope of your project, this may be a department head and her direct reports or it could include the CEO, the top executive team, and even the board.  So what do you want from the leaders? You want their sponsorship. The leaders have already signed off on your project or you wouldn’t be in business, but you need their visible and sustained support, not just their nods or shrugs. 

 

Leaders live in a world of massive demands on their time and resources. They are endlessly distracted and immersed in crises. So what do they want? They want to know that they made a smart decision in authorizing this project.  They want results, they want to know that you are going to succeed, and they want to look effective. You only have their attention briefly, so you want to focus on what you are doing to succeed. You can help them by

  • keeping your reports and presentations short and focused on results;
  • being realistic and straightforward about difficulties; most leaders know that things go wrong, but they are offended at feeling deceived, misled, or uninformed
  • providing materials for their own presentations and discussions with their bosses, board members, customers, financial analysts, and internal groups; leaders spend much of their time in these kinds of discussions and like having exciting, clear, and simple materials to use; it makes them look good; it also publicly commits them to you,

 

Never assume that because the leaders have approved your project that you are done.  Remind them what they have bought and why they have bought it.  Show them that they are getting what they decided to pay for. 

 

Your next key audience–and one that is almost universally ignored–is the managers who will be affected.  Never assume that because the leaders have said “yes” that you have the commitment or even the compliance of the managers.  In fact, never assume that anybody has told them anything.  The leaders always think they’ve communicated with their managers, but they probably haven’t. This group is simply taken for granted, but this is a huge mistake. Managers have strong, implicit veto power. They can decide, for example, that their people are much too busy to be released for training. What you want is for them to become active agents for your project. These are the real implementers. You want them to be willing to make efforts for your success.

 

And what do these managers want?  Managers often have the most to lose in organizational changes: they are under enormous performance pressures; they have succeeded with the old systems; and they live in a competitive world that gives them little margin for error or even experimentation.  They almost certainly see you as a cost, not as an opportunity. You need to help them discover how your project is good for them personally.  You build this support by:

  • keeping in daily touch with the business;
  • listening more than you talk, paying special attention to the managers’ expectations and concerns;
  • being realistic about costs, especially hidden costs around installation such as temporary reductions in efficiency, temporary opportunity costs, training costs, etc.;
  • most importantly, helping them see how your project will help them specifically.

 

There is no substitute here for face-to-face direct communication. You must go to them. This is going to take time, but it is time well spent. Your effort gives you credibility. You want the managers to want your project; you don’t want them either to misunderstand it or merely to tolerate it.  The marketing group I mentioned should have hungered for the new accounts-receivables project.  If managers want your project, it becomes an organizational priority, not another item to be moved down the list every time there is a crisis or another demand for resources.  Your goal is for these key players to want you to succeed.

 

Your third audience is your user community, the people who will actually touch and use the results of your project. You don’t have to sell these people, because they really don’t have a choice. Besides, users are less cynical than their superiors.  They may actually believe that you are going to help them do their jobs better. What you want is for them to become successful users, so don’t sell to them – educate them.  Your goal is to prepare them for installation. That is also what they want. They don’t want to feel stupid and inept. So start educating them and start early.

 

You likely became a project manager because of your technical skills. One of the hard lessons is that you will fail without political skills.  The technical skills with which you and your team create a first-class product are obviously essential, but they are not enough. Communication requires time and effort, but it is your job. You will win when you realize that effective communication is more about your audiences than about your project – about their hopes and fears. As you engage these hopes and fears, you may well discover that you are also becoming an expert in organizational communication.

 

Bill Roberts is the vice-president of TDF International and co-creator of TDF, a perceptual-styles theory. Trained in psychology at Purdue and Duke, Bill has worked as a psychotherapist, a professor, and a change consultant. He is the co-author of Finding Your Place: The TDF Map and numerous training programs. He can be reached at [email protected].

 

IT Program Management for Toronto Pearson

Written by Mike Morton on . Posted in Articles. 11 Comments on IT Program Management for Toronto Pearson

“Information Technology must not delay the opening of the new terminal.” This was the challenge issued in 2003 by James Burke, the recently appointed CIO at the Greater Toronto Airports Authority, the organization responsible for operating Toronto Pearson airport. The background to the challenge was that a $4.4 billion project to construct a new passenger terminal was already well under way and the IT department at the GTAA was still in a formative stage.

 

While the CIO and his management team focused on building an Information Technology & Telecommunications department capable of supporting the significantly expanded airport, the author was enlisted to lead the program to deliver IT&T systems and infrastructure for the new terminal.

 

There was significant catching up to do. It was important to establish IT&T as an integral part of the overall construction program and to quickly understand the needs of the many stakeholders. Even more critical was to establish a relationship with the construction program and make them aware that the IT&T program was dependant upon certain construction deliverables. As a result of this interaction, the construction schedule was revamped to accelerate an earlier than originally scheduled completion of the backbone cable and telecommunication rooms.

 

The scope of the IT&T program included over 700 passenger processing systems (combinations of computers, boarding pass printers, baggage tag printers, etc.), 100 self-service kiosks, over 700 electronic display screens, VoIP phones, a WLAN network, radio systems, and resource management systems.

 

All of these systems were to operate on a brand new infrastructure that included 53 telecommunication rooms and over 2500 kilometers of cabling.

 

Supplier Management

 

As all of the systems for the new terminal were procured rather than developed internally, supplier management became a critical function for the project team. In this context, supplier management included a transparent and challenge-proof process to select the best supplier/partner, the development of precise and comprehensive contracts, and the ongoing oversight of the supplier installation project.

 

A GTAA project manager was appointed to lead every significant project within the program. It was important to have the projects led by someone from the GTAA, not only to oversee the supplier’s performance, but also to manage the GTAA stakeholders, ensuring that the suppliers received clear and concise specifications as well as the ongoing and timely flow of information to the supplier’s project team.

 

The appointment of a GTAA project manager to oversee a project already staffed with a supplier project manager may appear to be a duplicate capital expense but it proved to be a sound investment with the cost of the project manager being offset by the avoidance of project delays and the management/reduction of change orders, etc.

 

 

Program Scheduling

 

There were absolute and critical dependencies between the stakeholder schedules.

 

The GTAA adopted a landlord model whereby it owns the entire IT&T infrastructure outside of the tenant spaces. The consequence of this model is that the deployment of IT&T infrastructure became a dependency for all of the operators and retailers moving into the terminal who required the IT&T infrastructure so they could install their own systems, phones, etc.

 

Schedule coordination between IT&T and the stakeholders became a full-time activity for several people to ensure that all parties could effectively schedule the activities for their workforces and meet their own target dates.

 

 

Milestones

 

The new terminal was opened in two phases. The first opening in April 2005 was to accommodate those airlines relocating from the old Terminal 1. During the three months prior to the opening, a series of operational trials were run, the most significant of which involved approximately two thousand members of the public acting as arriving and departing passengers. This event designed to test the operational passenger flows through the building also provided the first major test of the IT&T systems.

 

In January 2007, the second phase of the new Terminal 1 opened to allow the relocation of airlines from Terminal 2. Once again, all IT&T systems were in place and operational to enable this event.

 

The CIO challenge issued in 2003 had been achieved. The IT&T program was delivered on time and through effective management of the suppliers, the project was completed significantly under budget.

 

All told, it was an outstanding effort completed by a first-class team of project managers, technicians, and support personnel.

 

 

 

Derek Hyman is founder and president of Premium Technology Inc., a provider of project management consulting and training services since 1986. He can be reached at [email protected] or www.premiumtechnologyinc.com.