Tag: Leadership

Introduction

Factual and anecdotal evidence confirms that IT investments are inherently risky. On average, about 70% of all IT related projects fail to meet their on-time, on-budget objectives or to produce the expected business results. In one KPMG survey, 67% of the companies who participated said that their program/project management function was in need of improvement. Why? A number of leading factors for project failure were suggested by the survey, including the “usual suspects”: unreasonable project timelines, poorly defined requirements, poor scope management, and unclear project objectives. Granted, all of these factors can play a role in project success.


But are they the cause or project failure, or just a symptom of some larger issue? In this article, we will discuss that the root cause for many of these common failure points is really the ability to lead projects, not just manage them.

Leadership: Missing in Action

One would think that the proliferation of certified PMPs would have increased IT project success rates. However, given the research previously cited, this does not appear to be the case. Certainly, PMPs are cognizant of the processes, techniques and tools that should be used to manage projects and have documented project management experience. We contend that certification-the PMP-is indeed important, but that it alone is not sufficient for successful project management. Having been called on to rescue and turnaround numerous IT projects, we have had the opportunity to analyze why a project gets in trouble. As we looked at several of these troubled projects we realized that there appears to be a common link: leadership is missing in action. That is, while the project manager may be focused on what needs to be done and may well know how to do it, he or she may not be acting as a project leader. While certification is a good foundation for knowing what to do, it takes true leadership to drive complex projects to successful conclusions.

The PMI Body of Knowledge specifies five process groups for project management: Initiating, Planning, Executing, Controlling and Monitoring, and Closing. These five areas are consistent with the functions of management within an organization. Managers are responsible for planning, organizing, directing, resourcing, and controlling for the purpose of achieving organizational goals. The certified project manager should be able to demonstrate competent management of the nine PMI knowledge areas: project integration, scope, time, quality, cost, human resources, communications, risks, and procurement.

However, the ability to manage each of these project areas still may not produce successful project outcomes. Our experience on client sites for both government and commercial clients reveals that project leadership, not just management, is the critical differentiator. Project management without project leadership is likely to result in project failure.

Certainly, it is not our intent to redefine leadership. It’s already been defined as the ability to affect human behavior to accomplish a mission or the act of influencing a people to set and achieve goals. Volumes of business and strategy texts have been written about this critical competency. Check out your local book store and you will see numerous titles identifying leadership styles, leadership characteristics, and inspirational leadership topics. Some authors or practitioners have made the point that leadership and management represent two different skill sets and that either an individual has the characteristics and skills necessary for leadership or those more appropriate for management. Others have suggested that leadership is knowing where to go and that management is all about how to actually get there. We find this dichotomy troubling and perhaps at the heart of our IT project management failure rate. Instead, we believe that not only can project managers act as leaders, but in fact that they must provide leadership if projects are to achieve results.

A Closer Look at Project Leadership

Project leadership is all about shaping a team of diverse individuals (employers and contractors, some from different organizations) into a force that produces measurable project results. At our company, we recruit and develop project managers who can provide the leadership that complex IT projects require. At a basic level, project managers must be able to set the vision, define success, and determine the measurements of success. Then they must inspire, persuade, and lead the project team.

We argue that for project managers to become project leaders, they must demonstrate competence in essential skill areas. Successful project leadership involves:

• Leading courageously
• Influencing others
• Acting with resilience

Leading courageously is a critical competency because large IT projects have a huge resource pool representing different organizations and job roles. These resources may see their tasks slightly differently and may not all be aligned with project goals. Furthermore, the sheer number of issues and risks may make it difficult to zero in on those tasks that are most critical. In this kind of environment, leading courageously can easily make the difference between success and failure. Leading courageously means clarifying what is important and taking a stand to resolve important issues. It also requires driving hard on the right issues and confronting problems promptly. Finally, courageous project leadership means being decisive and challenging others to make tough choices.

Influencing others is an essential competency for most projects, but especially for those with large project teams, numerous stakeholders, and different user communities. Influencing others means giving compelling reasons for ideas and suggestions and winning support from others, both within the project team and in the user and stakeholder community. It also requires the ability to negotiate persuasively and get others to take action. Finally, it means influencing the decisions of upper management, whether within your own organization or the client organization.

Acting with resilience is critical to project leadership and is especially important when projects are at critical stages or in trouble. When a project manager acts with resilience, he or she keeps the focus on project goals and refuses to give up. Sometimes it means being tough enough, in the face of adversity, to fight the good fight and get agreement on issues that threaten to derail the project. Or it may simply require being flexible enough to negotiate solutions that keep driving for the goal of project success, when others might give up and accept defeat.

Summing It Up

In this article we’ve presented the case that project leadership is the differentiating factor in project success, especially on large, mission-critical projects. Knowing what to do and being able to manage the nine knowledge areas identified by PMI is not enough on complex projects.

Successful project managers must lead courageously and be able to influence others to resolve some of the most critical problems that projects experience. And to paraphrase Churchill, they must never, ever give up; they must act with resilience even in the face of conflict and problems. To experience the project success that investments demand, assign project managers who can act as project leaders to your mission-critical IT projects.

Dr. Karen McGraw is the founder, Chief Knowledge Officer, and past president of Cognitive Technologies. Dr. McGraw has extensive experience in technology-based performance improvement solutions ranging from the design and implementation of computer-based learning and learning management systems, to expert systems, performance support systems, intelligent interfaces, and knowledge management systems. Dr. McGraw is a co-developer of the Performance DNA toolkit for analyzing human performance to diagnose improvement opportunities. Dr. McGraw is nationally recognized in eLearning, knowledge acquisition, scenario-based requirements, and performance analysis and design and has authored five texts, including User-Centered Requirements and Knowledge Acquisition: Principles and Guidelines.

When project management software is presented by their vendors these days, we tend to hear the ‘core’ subjects: critical scheduling, portfolio analysis, resource capacity planning, risk analysis, inter-project reporting and so on.  If you’ve not been in one of these demonstrations before, you’re missing something.  They’re a sight to behold.  The software sits up on its hind legs, barks and then runs out to get you a cappuccino.  Ok, maybe not quite.  But these enterprise project management system presentations are pretty impressive.

I’ve been in the background of preparing such demonstrations and I can tell you that an enormous amount of work goes into them.  It’s easily understood.  The software vendor doesn’t want to show what the software will look like when it’s delivered, they want to show what it will look like after it’s been adopted, used, updated, personalized and is delivering the great results the client is hoping for.  To be fair, that’s what the prospective client wants to see too.  They want to see a finished product looking like it would if they had completed their implementation.

To prepare such demonstrations an entire fictitious organization must be created.  It’s not enough just to imagine some tasks because, just like a real organization, all kinds of data must relate to all kinds of other data and this means assembling a story.  Once the story is written, the data must be created to match it and then installation and configuration of the software has to happen.  There are also reports, views, filters and such to be created, so that the prospective clients can see how everything fits together.

I bring all this up because what often happens during these presentations is that the prospective client gets very excited about the delivery of a solution that will solve all their problems; the “silver bullet” solution (of Lone Ranger fame) which will always reach its target no matter how far or how small.

The truth is, some of these answers are hard to come by.  I’ve found over the years that the most requested solution by organizations seeking an enterprise project management solution is “Resource Capacity Planning”.  This is unfortunately the first thing (and sometimes the only thing) they ask for and it’s almost always the last thing I can deliver.  It’s not that I’m being difficult, but creating a resource capacity planning solution implies a lot of underlying assumptions to be resolved.  First, you must have 100% of the resource availability. Next, you must have 100% of the resource load which must be organized by task.  These two items are just the collection of the base data required for a resource capacity analysis.  These items alone are so daunting for most organizations that just overcoming the cultural challenges required to get all the data will overwhelm the project.  If we overcome these, we’re still not done.  We need a prioritization process that identifies which work should get first access to restricted resources.  We need a process that will have everyone update the resource availability and requirements on a normalized basis.  We need analysis and reports that make sense of what may be an enormous volume of data.  We need metrics to determine what the reports mean and, finally, an action plan which fits into our process to take the appropriate action where the metrics indicate.

Whew!  I know… It’s daunting, isn’t it?

In a mid-sized organization, delivering this kind of EPM solution can take up to two years or more.  Some results can be produced much faster but there are some much more interesting aspects to software deployment in the enterprise project management context when we look outside of the core project scheduling functionality.

First of all, there is a huge range of online training in soft skills.  You can take courses in leadership, negotiation, assertiveness, communications and dozens of other subjects.

If we take a look at communications for a moment, the whole domain of online collaboration is a huge area of benefit.  You can use Microsoft’s Windows SharePoint Services to create online portals for project work.  Windows SharePoint Services is included as part of Windows Server and includes the ability to create event lists, lists of contacts, tasks, file sharing, document management and more.  If you’d rather not install software, you can look at services like Google Groups.  On Google, you can create a private group for your project team and store up to 100MB of files, start discussions, make announcements and share information no matter where people log in from.  You can tie Google Groups with Google Documents and Google Calendars to share a wider range of information.  If the group is small, the functionality may suit you rather well and you can’t beat the price.  It’s free.

If you’d prefer to do something a little more involved, there are a number of content management systems such as PostNuke, Joomla, Drupal, DotNetNuke, and DotProject.net.  These systems can be installed or hosted almost anywhere, and provide a rich environment for creating a communication and collaboration environment.  Data of almost any kind can be stored and, when it’s your own system, you can tweak it and customize it and even add on to it to your heart’s content.

For some the key is managing documents and there are a number of solutions for this challenge as well.  If the requirement is for a small team, both Google Documents and Google Groups offer a lot of functionality for no cost.  If you’re keen to go a little deeper and host the solution locally, you can do basic document management with Windows SharePoint Services.

There are also a number of free document management systems (dms) available for download which include a much richer level of document management functionality.  Examples would be OpenDocMan, Epiware (which also includes tasks and a Gantt chart!) or DocumentManagementSystem (on www.SourceForge.net)

If what you really need is a centralized location, where all your research can be compiled and added to and updated by different team members, then creating your own Wiki is the way to go.  Made famous by the Wikipedia folks, you can install your own Wiki software.  There are dozens of free versions.  Just search for “Free Wiki Software” to see the most current.

These aspects of your project management environment may seem like ancillary functionality but make no mistake about the potential for these aspects to deliver a tremendous impact.  Implementing an effective communications process where there was none before can seem like the difference between night and day. Introducing a collaborative commitment tracking system can deliver instant focus to a team that might not be co-located.

One of the most powerful things about these aspects of the enterprise project management environment is that it can be very, very fast to deploy compared, say, to resource capacity planning.

We’ve talked a range of alternative software systems for working on aspects of your project management environment that are outside the core scheduling capabilities but of course much of this kind of functionality can also be found woven within the major enterprise project management systems on the market today.  If you’re evaluating whether to use these commercial systems to work on these other aspects of the project management environment, then make sure the benefits of these areas can be delivered without first getting all the core scheduling organized as part of the same exercise.  Some EPM systems are schedule-centric.  They were designed around the notion that the schedule would be the key element around which all other data and all other functionality would be tied.  No centralized scheduling for these systems means no centralized anything.

There are many paths to delivering effectiveness in your project management environment.  You don’t have to settle for the most obvious.  With so many different tools and services available immediately, it is within your power to make an impact in a very short amount of time.

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].

1. It is best not to share the project plan with the project team as it leads to unnecessary and usually incredibly stupid questions.
   
   
2. Mandate that team members submit task duration estimates as precisely as possible: two decimal digits (e.g. 17.36 days) are usually sufficient but some projects may require three digits.
3. Strive to disperse project team over multiple locations: it greatly reduces the time people waste mindlessly chattering with each other.
4. In this economy, everyone ought to be able to work harder. Schedule tasks based on 10-hour days.
5. Involve the Steering Committee in day-to-day running of the project. They will tell you how much they like it.
6. When briefing the Steering Committee, it’s a good idea to declare all nearly completed tasks as completed. Ninety per cent is awfully close to 100 per cent and the Committee Members will feel encouraged.
7. Try to surprise your Project Sponsor every now and then. Rescheduling the implementation date, firing half of the team or changing the vendor half-way through should all be considered.
8. Status updates clutter mailboxes, so avoid them.
9. Get rid of those team members who disagree with you. You are in charge of a critical project and the last thing you want around is some worm questioning your decisions.
10. Don’t waste any time trying to understand the business domain. It is unimportant and is not your job.
11. A list of typical project risks can be easily obtained on the Internet. Don’t waste precious time developing it; this is merely a formality.
12. Act professionally: don’t engage in unrelated conversations with your staff and certainly avoid socializing with them. It is important to maintain a distance.
13. Information Technology is an exact, predictable field. If your programmers cannot write code without any defects, replace them.
14. To speed up negotiations with vendors, just sign their canned contracts.
15. Details are unimportant; the job of the project manager is the overall supervision.
16. Once the scope of the project is determined, ensure that it is impossible to change it.
17. A lot of people may claim to be project stakeholders. Feel free to ignore those you don’t like.
18. Encourage team members to decide for themselves what their tasks should be.
19. The best way to gauge the skill of a fellow project manager is to ask them about the largest project budget they’ve ever been responsible for.
20. Plan to release the project team on the day of implementation, to save money.

(Bonus) Forget that it’s April Fools’ Day and start typing an angry letter to the Editor.
Remember that it’s April Fools’ Day when you’re on the third page of it!

Ilya Bogorad is the Principal of Bizvortex Consulting Group Inc, a management consulting company located in Toronto, Canada. Ilya specializes in building better IT organizations and can be reached at [email protected] or (905) 278 4753

Villanova University First in Market to Incorporate New PMBOK® Guide –
Fourth Edition Into Online Project Management Programs