Stay tuned. I’ll be blogging from the floor of the Microsoft Project Conference in Phoenix this week as Microsoft kicks off its promotions for what’s to come in the next year with Microsoft Project, Project Server and Portfolio Server.
Over the next few days, the Non-Disclosure agreements for much of what is in Project 2010 will expire and we’ll be able to talk a lot more about what you’ll find in the next version of Project here in the blog.
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.
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.
Ahh the pilot project. It’s a term that software sales people hate to hear but almost every major software implementation project works its way through this phase. Even I have recommended using pilot projects as a safe way of determining the suitability of software for a particular purpose.
The notion of a pilot project isn’t new. The idea is to implement the entire software solution being proposed on a minor scale with real data to see if it can meet the needs of the organization. Often, just like in drug testing, there is a ‘control group’ and a ‘test group’. These groups are best organized as similar sized departments with a similar workload. The test group will use the new system, the control group will continue with normal procedures. At the end of the pilot, the performance of both groups will be evaluated and the relative efficiency of the new system can be measured.
It’s a great plan. After all, the only change between the two groups will be the introduction of the new software so the effects should be easy to test. For people who have just finished their MBA and are now working in the middle-management ranks, this provides perhaps the only opportunity to determine a Return on Investment (ROI). This is particularly difficult to come up with otherwise with certain systems such as project management software where the hard-cost benefits are difficult to determine and the soft-cost benefits such as bringing in the project early are tough to prove in advance.
The final result of the project is the identification of the right software to implement and even some tips on how to implement it. All of this at little to no cost, right?
So, if it’s such a great plan, why aren’t more pilot projects successful? Often a pilot project is undertaken only to find out that the results are never tabulated or that the results are delivered but they result in no decision or that the project is terminated prior to completion.
There are a number of hidden challenges in a pilot project which must be dealt with if you are to have any chance of success.
First of all there is a fundamental underestimation that I find in almost 100% of pilot projects which I encounter. Often the software itself for such a project is offered for little or no cost and the assumption is then made that the cost of the pilot project is therefore zero. When we’re talking about an enterprise system, nothing could be further from the truth.
In order to see the results of any enterprise software system, it must not only be installed, it must be implemented. As anyone who has done such an implementation can tell you, the costs of installation and purchase of the software are often dwarfed by the size of the rest of the implementation budget. There is legacy data to be configured and uploaded, the configuration of the system to be determined, reports and entry forms to be created or adjusted, training, more training, external systems to be linked, practices and procedures to be created then adopted and, (did I mention?) more training.
This is so whether you are looking to try the system out on one week of data or one out of fifty projects or one out of 20 departments.
Once a system has been implemented, expanding its use to the rest of the company is an incremental cost which is the least costly and least effort of the project overall.
An implementation of an enterprise system of almost any kind for the first department or first project or first core element of an organization may be scheduled to take weeks, yet, so many organizations that I speak to talk about a pilot project like it will take a week of effort and will cost the organization nothing.
Without an understanding of how much effort such a pilot will really take, management can quickly become frustrated and your sponsorship of the project will be in jeopardy.
Even if there is adequate management support, there are a few other pitfalls to overcome. First of all, it is ongoingly stunning to me that almost no pilot projects I encounter actually have metrics, for how the test will be measured. I see this over and over and over again. When pressed to how the pilot team will know that the test was a success (or even if it’s complete) the general feedback seems to be “We’ll know.” As though some feeling will be imparted to the team when the system is good enough.
Also, for the test to be fair, there should be no other influencing factors that would mask the effectiveness of the system in question. That’s great but in today’s business environment, everything is changing all the time. And actually isolating a team to avoid such influence would be an unnatural influence by itself.
It’s also worthwhile to mention that the implementation of any significant change in the systems of a group almost always results in a short-term drop in performance as the personnel adjust to a new way of doing business and as the analysis or data from the new system is integrated into the group’s decision making process. Very short term implementations such as a pilot program may show negative results where a longer term perspective might show a better example of the potential benefits.
So, is it hopeless, are you now reduced to choosing software from the description on the side of box? It’s not quite that bad. For some types of software, it is easier to implement a pilot than others. If we take project scheduling systems, for example, it is relatively easy to have one department work with one tool while the rest of the organization works with another. You can even have implementations done by staff who have been previously familiar with different tools to show how they can be put to their best advantage.
For other types of software, however, pilot projects may not be your most effective evaluation method. You might use other tools such as reference site visits or the use of an independent consultant to help shape the overall implementation plan. This cost and effort would be recoverable regardless of which system is ultimately selected and is often very revealing to the internal cultural issues that will need to be overcome to take advantage of the enterprise system in question.
One way or the other, the most important thing to remember: pilot projects aren’t free. Make sure you’re getting a good return on investment on the effort and money that the pilot itself will cost.
There’s been a lot of project management going on in our office lately and it’s allowed me to do something I usually don’t make enough time for and that’s training project managers. To add to this already interesting task, I had the privilege of addressing McGill University’s project management students this week and found enough commonality between my staff and the McGill students that I thought I’d share it with you.It seems to be almost universal that when a new project manager starts to manage projects that they are firmly convinced that if only they were in charge, everything would be fine. I watched 2 students this week working on an assignment in class just prior to my lecture where they were asked to organize a company in such a way as to make the project management as effective as possible. Oh if only it were so easy.
These students were worrying the company’s organigram trying to ensure that they would have sufficient authority to effect the changes required. Sure enough, the first question posed to me by the students in class was the first posed to me by my own 2 new project managers inside our firm; “How does the project manager get past the interference (sorry I meant help) of management?”
If you’re a manager and are now getting hot under the collar, you’ve probably heard this before. New project managers seem to always confront this difficulty and those that cannot resolve it don’t remain project managers very long. In an organization, which does more than one project, the most common structure for operations is a Matrix organization where project managers are responsible for specific targets, which we measure in work output and line or resource managers are responsible for the departments whose employees must deliver that work.
The resulting conflict between resource managers and project managers is inevitable and perhaps healthy but for those who think that their perspective is most important, it can be intensely frustrating.
The project manager trainees who I’ve been working with this week wanted to know how they were to acquire the authority to overrule all those resource and line managers in order to accomplish the projects they would be assigned. It was left to me to deliver the bad news. With the possible exception of mega projects where there is only one project going on at one time, project managers are almost never given such authority and it doesn’t take much thinking to see that they shouldn’t be either. Left to their own devices, a project manager would burn staff out. Oh, they’d take care of them for their own project of course, but there would be no allowance for the rest of the employee’s life. If a staff member is absent for 4 and a half days with no excuse, that’s a critical even for the that person’s resource manager. I mean, are they still working here? Are they sick, are they dead? Should I replace them? It’s a big deal. Yet, if I go to a project manager and say “Did you hear about John? He was absent for 4 and a half days last week?”, a project manager is entirely likely to ask me only about the 4 hours during which the person was present “Did they work on my project while they were here?” After all, that’s what is of interest to the project manager.
Project managers also have a horrible reputation for ignoring the requirements of other projects within the organization. When I ask what priority a particular project should have company wide, the answer from the respective project manager is inevitably “at the top”.
How then can a project manager get the resources and attention they need to accomplish the targets they have committed to? Here’s the answer I gave my staff last week. “You’ve got to plead, beg, grovel, demand, enroll, convince, ask, suggest, insist and cajole to get the resources you need. What you can’t do is instruct.”
The natural conflict that then arises between the resource manager and the project manager is one that is common to almost every high-tech company in the world. We’ve taken to using advanced technology to deal with this conflict both within our firm and recommending the same technology outside the firm. What is it you ask? A collaborative web-based tool? An on-line project resource reconciler? No. We make the managers actually talk to each other. I know it sounds trite. But it’s an element of project management which is becoming scarcer and scarcer. We setup a structure whereby the line managers and the project managers must meet on a regular basis to talk about resourcing priorities. Amazingly, they seem to resolve all outstanding resource conflicts without much difficulty on a regular basis. It’s the regularity of it that makes the biggest difference. You can have an argument if you like, but you’re going to be right back here next Friday looking at the same person with the same challenges. It’s makes for a big incentive to get along.
It’s not to say that the latest updates in project software don’t make a difference, they do. But when you use technology to replace human interaction, you do so at your peril. It’s humans after all who will have to get the work done and cooperation between staff can’t be mandated like a feature in an application.
It’s enhancing this human interaction that software is supposed to be best at rather than replacing it. Collaborative project tools are excellent enhancers when a culture of communication is already in place but if these managers aren’t ready to even talk to each other, great software features can’t make a difference.
No matter what the application is, you can’t ignore the human factor and the more of the enterprise that is implicated in a particular corporate system, the more impact the human factor has.
It’s the path of least resistance that is the root of most problems with implementing enterprise project systems. You no doubt have heard the term. It’s commonly used to describe the path water will take if put on an uneven surface. Water will always flow down the path of least resistance, forever taking the easy way to lower altitudes
In the world of project management systems, the term is an easy analogy to adopt if you start to look at enterprise systems. If you’re just looking at a desktop scheduling tool then this whole notion may not play such a key role. In this case, an individual might be willing to tackle a path that is quite difficult including a steep and high learning curve, software which is not simple to install or use and a process which must be defined by the user. An individual might take on such a system in the interests of furthering long term goals of either the company or him/herself.
But what hold true for an individual often does not work for a group. I’ve seen more and more organizations this year striving towards an enterprise project control system. Sometimes the project is underestimated (Ok, almost always) and sometimes the project has many cultural hurdles to overcome (Alright virtually always) but one obstacle that seems to virtually always appear is often not identified as a problem at all and that’s the tendency of people to follow the path of least resistance.
I’ve come across it several times in just the last month. In a huge insurance company based in the US, they have been striving for a common project management system for over a year (at least publicly – They’ve probably been trying to decide on such a system since the company was founded!).
This year I was peripherally involved in the selection process. Fundamental to this process was that a single product would be chosen. Over 300 people were canvassed as part of the due diligence process. “We didn’t want anyone to feel left out,” said one senior committee member. “We need universal buy-in.”
After almost 16 months of sometimes intense internal negotiation, they have now told the 3 product finalists that the “standard” project management tool that will be chosen must be able to integrate fully with Microsoft Project as it will continue to be used by project managers across the company whenever they feel the need is warranted.
Now, I’m on record as saying that I like Microsoft Project just fine but it must be obvious to you that choosing a “multiple-product standard” is an oxymoron.
How can an organization take two products; one a desktop planning tool, the other a high-end enterprise project control tool and make them an integrated project management system for the entire enterprise? Well, they can’t. Oh, you can declare that such a system is now your enterprise project environment but that doesn’t make it integrated.
The problem is that different people have different needs. It might be better in the long term for the organization to work with a complex but extensive project management system but end-users who don’t see a direct benefit to them won’t adopt it. They will follow the path of least resistance; choosing a system which can return them results instantly. Full-time professional project schedulers see their path differently. As an individual who is often asked for reports and analysis, they might find the path of least resistance to be in a high-end system with a lot of flexibility.
So, will this company implement an enterprise project management system? Not this year.
I’ve seen the same phenomenon at the management level. This month, while advising a multi-national pharmaceutical company, I watched a senior executive follow the path of least resistance into a no-win situation.
In this firm, the senior executive in a research group, created a committee to select an enterprise project tool. It started off with a great deal of momentum and lofty ideals. But, as many committees do, over time, the diverse interests of this group started to show through. The selection process should have been complete in a few short months. Instead, some 18 months later, it’s now more mired in controversy than ever.
The senior executive, has had several opportunities to move the process forward at the risk of upsetting some of the committee members but he won’t. He takes instead, the path of least resistance. He has always managed through consensus. His theory, is that everyone just stays in one room long enough, eventually they’ll come to the same conclusion. The underlying assumption of this theory is that there is common ground to be found somewhere. The problem is, there are different kinds of tools appropriate to different kinds of users. Consequently, the longer the committee struggles, the more each diverse interest is attracted to a different kind of tool. Without the intervention of someone senior in the process the committee has no hope of success.
So, is there any defense against the path of least resistance? There is. The two best weapons against the dangers of following the easy road into trouble are commitment and structure.
Commitment is the tougher of the two and is most likely to be seen at the executive level. If you know that you or a committee or group you are sponsoring may be enticed down the garden path of least resistance, you can keep them productive by committing to a goal that goes beyond what is easy. Kennedy did it when he committed to send a man to the moon before the end of the 60’s. When he consulted the project managers they said that the project was impossible in that time frame. But his commitment had inspired the country and many men and women toiled to make the commitment a reality even against tremendous opposition and adversity.
If you’re not the President yet you still want to make an impact in this area, you can do so with the second great weapon; structure. Even the lowliest project system selection committee member can introduce structure into the selection process. Structure can usually be introduced at low stress without offending anyone from any faction.
Once the structure has been agreed to, it becomes a powerful backdrop against which to move the process forward. It may be one of the few elements of the group’s entire history on which everyone was able to agree and thus it can become a focal point for progress together.
Whichever method of combating it you choose, don’t discount the insidious effects of following the path of least resistance. Remember this Chinese proverb – if you don’t change your path, you are liable to end up where you are headed!