Author: Haydn

We hear this all of the time – project management is the “accidental profession.” Very few of us went to university with the objective of being a project manager, nor did we enter the business world with that objective. Somehow, through the course of human events, we ended up at the wheel of a scheduling management tool, and we stumbled into a new career. This pathway to a role in the world of projects is not restricted to the project manager. Project sponsors also end up in their role by accident; often with little personal focus towards that role, and with little knowledge of what they are supposed to do. As project managers, it is up to us as to train and leverage this reluctant resource. We need to teach without lecturing, and engage without monopolizing the precious time of the senior executive that serves as “the accidental project sponsor.” Here are a few techniques you can start using today, as we walk this tightrope in the “mahogany row” hallways of the businesses we serve… 

Don’t tell the sponsor what to do, ask about acceptable techniques

Senior leaders are used to carving out their own way and capitalizing on approaches that are comfortable to them as individuals. Telling them what their role needs to be is rarely an accepted approach. Define your own role as the project manager through the eyes of the sponsor, while at the same time asking when and how the sponsor wants to be engaged in project decision making.

It is a good idea to have a checklist of things that you feel you need from the sponsor; you can share that checklist if you believe it will be well received. In cases where you don’t think it will be taken appropriately, prioritize the items on the list in the order in which they will have the greatest impact on the project or will require the greatest degree of time and attention from the sponsor. Ask how and under what circumstances the sponsor wants to be involved and informed in that area of the project, focusing on what authority for decision making you will take on as the project manager. When you understand the limits of decision making the sponsor will provide to you as the PM, it then leads to an opportunity for productive dialog about sponsorship activities. Asking the question “When a decision has to be made and reaches beyond the limits you have defined for me, how would you like me to engage you in that decision, and what information would you like me to bring to you to facilitate that decision making?” can be a powerful tool. Along the way, in striving to receive an answer to that question, you can certainly make suggestions about that process and the data you provide. In that way, you are actually educating the new, accidental or hesitant sponsor, without preaching about what they “should be doing.”

Bring multiple choice questions/options to every discussion

Don’t bring problems to the desk of the project sponsor, bring options. This technique, if used consistently, does put a burden on us as project managers. However, if we don’t have time to do the research to understand the pros/cons of the various options that we believe should be considered, certainly the project sponsor won’t have time to perform this analysis, and the decisions we need won’t be made. The formulation of those options and the resulting consequences are relatively straightforward. Just apply what we have learned through PMI and via good solid project management training. First and foremost, define the probable impact on the triple constraints of time, cost and scope. Secondly, determine the impact on the quality of the project’s product. Lastly we need to consider an area that usually is very important to the project sponsor, but is often overlooked by individual project managers: examine the impact of changes to your project on the other projects being championed by the sponsor. This involves talking to other project managers and making sure you are aware of the status of other initiatives. Remember, our sponsors are often in the same “accidental” role for other projects as well – if you are looking to a sponsor to provide a decision, and you don’t provide data as to the impact on other initiatives, you are very unlikely to get a decision. Rather you will get a “send away” to do more research, or more often than not you will get a “I need to consider this” type of response, that goes unanswered for a long period of time, if at all.

Make communications short, to the point and relevant

We all receive a large number of emails, especially as we work in a world with more home based offices, virtual teams, and international initiatives. In my experience in managing project teams and IT delivery contracts, I have managed teams as large as 460 people. Regardless of the environment, one thing is constant – the flood of emails. In my experience, that flow is actually quite consistent. On an average day, the number of emails I receive is .85 times the number of people I am managing. Consider that when working with your project sponsor – if your sponsor is managing a team of 460 people, he/she is probably receiving well over 350 emails a day. Considering more and more senior leaders are making due with a limited amount of administrative assistance (or none at all) just keeping up on emails can be a daunting experience. How is this done? Senior leaders rarely read their emails in their entirety – they skim them for context and relevance and sometimes don’t even get beyond the subject line.

We always hear about “email rules” that talk about using relevant subject headings, and brief sentences, with no more than two paragraphs, etc. In the case of sending emails to the busy sponsor, the use of these email principles is absolutely mandatory. Get to the point, say what you need, present the options and a short snippet of the pros/cons and be done with it. If you need to communicate more extensively, state the subject and why it is important (hopefully by reflecting on the techniques discussed in the first bullet of this article, or something like it) and request a discussion. Schedule it for 15 minutes, no more, and practice getting your point across in that period of time, while allowing for questions and clarifications from your sponsor. If your sponsor wants to discuss this for longer than 15 minutes, they will, or will ask you to come back at a time that is convenient for them. Either way, you are sure to be communicating, instead of attempting to communicate via a drawn out email that is unlikely to be read.

Strive to understand where the sponsor feels they are succeeding and needing to improve (hot buttons)

The successful project manager understands the product technology pertinent to their project; however they also know that, at its core, project management is a “relationship business.” We do need to understand the tools of our PM trade, we need to fully understand our area’s processes, and we have to ask the right technical questions to be sure we are producing the right product in the most efficient manner. This all falls by the wayside if our relationships with our highly matrix oriented team members and our sponsor are not sound and strong.

The best way to develop that relationship and receive the support of a very busy sponsor is to know what is important to them. “Feeding” them in ways they need feeding is the most efficient way to do this. Through discussions with the sponsor or others around your sponsor, determine what they feel is going well in their organization, and what areas of improvement they are seeking. Tool your project objectives and risks around these areas, highlighting how your project will positively affect those areas of the sponsor’s business or how risks might jeopardize them. That way you will keep relevant in the eyes of the sponsor and you are more likely to get the time and effort you need from that stressed individual that is the “accidental project sponsor.”

How do you know you’ve sufficiently tested the product your company is eagerly waiting for? This is probably one of the most difficult questions for a project manager to answer. Undoubtedly there is some “grayness” to determining when testing is completed, but that doesn’t mean you can’t add some “science” to determine if your product has been tested “enough.”

Success in testing requires that a testing process be created and followed. Without a process there is no way you’ll be able to determine if the product has been sufficiently tested. Typical testing processes include:

• Testing Strategy document
• Test Plans for each testing phase (for example; unit, integration and system testing phases for IT solutions)
• Developing test cases
• Creating test data
• Executing test cases
• Recording the results
• Evaluating the results

Without a testing process you’re “flying blind” … it’s similar to trying to cross a 4-lane road in the middle of the day on a heavily traveled street. If you have a process to follow (i.e. go to the designated crosswalk, press the pedestrian cross button, and proceed to cross when the walk indictor has illuminated), your chances of making it to the other side of the street are greatly improved. If you attempt to run across the street randomly, the results probably won’t be favorable! Testing without a defined process can be equally catastrophic.

Testing is one area of project management where tools can be immensely effective; specificallyspecifically, a traceability matrix. A traceability matrix can be used to record each requirement and ensures that test cases are built to test every requirement. The traceability matrix will help you determine:

• If a particular requirement is missing a corresponding test case (oops!)
• If a test case is too complicated due to testing many requirements
• If a test case has been created – but does not have a corresponding requirement because the requirement was removed from scope
• If a requirement is too complicated or over-tested because it’s being evaluated in too many test cases
• Testing status per requirement via color coding when a test has successfully completed or when defects have been identified

A traceability matrix can be created using a spreadsheet or any database tool such as MS Access. For a sample traceability matrix you can email me.

Assuming you have a documented (and used!) testing process and you have a traceability matrix in place – you’ve armed yourself with some critical information to determine when you’re done testing. Do all requirements have at least one test case tied to them? If not – you’re probably not testing the solution sufficiently. Conversely, if a given requirement has more than five test cases to evaluate it, that particular requirement is probably being over-tested.

The next characteristic to examine is defects.  First, determine the number of defects identified for a given test run (several test cases should be executed during a test run). Next, determine if the number of defects are increasing or decreasing for each test run. The first time the test run is executed, expect to find a high number of defects (because the whole goal of testing is to find defects!). The 2nd run (of the same set of test cases) should have fewer defects. By the time you execute the 3rd run – your test run should be surfacing even fewer errors, and certainly lower severity defects. If the number of defects is going UP per test run, you are obviously not nearing the end of testing. In fact, this may be an indication that when defects are corrected additional errors are being introduced. More than likely the person correcting the original defect did not sufficiently unit test the product prior to returning it to the test run environment.

So, how do you know you’re done testing? Here’s a general rule of thumb. Once each requirement (based on the traceability matrix) has been tested and yields no defects or low severity defects that can be corrected later, the product is ready for “prime time.” Could I test longer and find more defects? You bet – but the time is takes to find those additional defects is usually not worth the team’s time and effort.

If you’re receiving pressure from your management team to reduce the duration of the testing effort to meet schedule constraints (and they are not able to provide you additional resources to perform the testing) plan a meeting with your business management representatives so they can review the traceability matrix and indicate which requirements do not need to be tested prior to implementation. This approach moves the decision making process where it belongs, with the business. The business knows better than you do which requirements are essential for their day-to-day operations. By showing management how the traceability matrix is driving the testing schedule they become better educated on how detailed the testing process can be. Sometimes management will then extend the scheduled implementation date or provide additional testing resources to ensure all test cases are executed as planned. If a decision is made to not test all requirements prior to implementation, a risk strategy should be developed to prepare for the potential impact of having numerous defects post implementation.

Another technique to determine if you’re done testing is to examine the percentage of defects identified based on the number of test cases executed in a given test run. If you executed 100 test cases and more than 10% had high severity defects – you’re not done testing. However, if you executed 100 test cases and you had no high severity defects and only 10% medium to low severity defects identified – you’re probably there! Work with your management team up-front to determine acceptable variances so you’ll know when the product is “stable enough” for implementation purposes. These percentage guidelines will vary greatly based on your industry and the type of product being implemented. The key is having discussions with management early in the project lifecycle (when the test strategy and test plans are being developed) to determine appropriate acceptability or exit criteria for each of the testing phases.

The “timing” of the defect makes a difference too. I EXPECT to find defects in the initial phases of testing. As you get further in the testing lifecycle and you’re doing final Quality Testing, Operations Testing or User Acceptance Testing – only minimal defects should be identified during these stages of the testing lifecycle. If you’re finding numerous or high severity errors – this is an indication that you are NOT ready for implementation and you need to consider doing additional testing prior to implementation (or prepare for more problems when the product is implemented and position the company to provide the additional support necessary to handle the “less than perfect” product.)

Testing is an art – but adding a little bit of science to this area of project management will help you feel more confident that you’ve tested your solution “enough”. If you establish and follow a testing process, you can determine when the solution is stable and ready for implementation.

The project manager’s ultimate responsibility is to protect and promote the business for whom he is working. Towards that end, the project manager works diligently to produce the best business results, meeting or exceeding the objectives of the “triple constraints” – scope, time and resources. However, there are a number of instances where the astute project manager will realize his business is on a pathway to failure. These situations need to be addressed and assessed against project objectives or corrected before the business suffers avoidable losses. The initial approach for the effective project manager is to remove the hurdles that impede her project. Sometimes however, that cannot be accomplished easily. In these cases, the project manager needs to take a profoundly opposite role – they need to become a hurdle – a hurdle to impending disaster. This role as a hurdle becomes vital when the organization is unlikely to “back off” the execution of a project even if there is little chance for project success. Some of the more common circumstances that lead to the demise of projects are addressed here. When these surface, it’s “hurdle time” for the courageous project manager!

Projects with pre-defined triple constraints

The trend is very disturbing – a large number of projects come with all of the triple constraints predefined. The project manager is told what will be produced, how long it will take and how much it will cost. Pre-defining the triple constraints is a short sighted sponsor’s approach to “being a strong leader” and it just doesn’t work. How often have you taken your car to the service center and told the mechanics what they will find when they peer under the hood, told them what time they will have your car available for you to pick up, and how much they will charge you for the service? Of course we don’t do this with our cars! Accepting a project of this nature without questioning the sponsor is irresponsible. Projects need to be examined for the credibility of the desired outcomes, imminent risks, and evaluated against the organization’s available skilled resources. Except in cases where there is a very well documented and understood history of analogous projects in the sponsoring organization that validate the predetermined triple constraints, projects will all three triple constraints pre-defined will not succeed.

With the ever increasing demands on senior leaders – be mindful that they too are trying to do more with reduced numbers of resources – the details and challenges that are everyday issues for the project manager don’t always enter the mind of the project sponsor. Tactful and tactical approaches – like asking to conduct a short investigation – can bring these potential issues to light, giving the project manager some “breathing room” to negotiate the expectations for the project. At the very least it provides a means to identify risks and potential response actions to increase the chances of meeting the expectations for the project.

This is an example of the project manager presenting an appropriate “hurdle” to what the organization is asking. There are many examples of these projects however – here are some additional cases.

Projects that change processes, without appropriate business analysis

Another common way to poorly conceive a project is when the deliverables for a project involve changing tools and business processes simultaneously and analysis of the “as-is” and “to-be” business environments are not considered as part of the project scope. Automating a process that is not well defined or implementing new or changed automation without the appropriate examination of the existing and new business processes results in disaster. Examples of this abound, as evidenced by the large number of failed projects in the Enterprise Resource Planning (ERP) space, using extensive product suites such as PeopleSoft ®, SAP®, and J.D. Edwards®. These software suites are quite capable – but they are frequently installed in hopes they will facilitate the improved execution of existing business processes. It doesn’t take long for the users to report that the product doesn’t work. The reality of the situation is this – the software suites do “work,” just not to facilitate the precise business process the users are trying to execute. A significant mismatch exists between the processes the users are accustomed to executing and the processes that are inherent in or implied by the software.

Projects that seek to change both processing tools and the user’s business processes need to contain a number of required initiatives in order to succeed. These initiatives include an analysis of existing business processes – the “as-is” model. Only with a well defined set of current processes will the project manager and her team understand what processes are going to change, where current complexities exist, and areas for improvement – and therefore what needs to be communicated and taught to the user community.

The second major required initiative for these projects is the definition of the “to-be” model – the set of processes that will result from the project deliverables. ERP product suites have an implied set of processes inherent within them. The providers of these software tools seek to support and promote business processes that reflect common practices across a broad swath of industries, as well as focus on “best-practices” to achieve efficiencies across the organization. Inevitably however, the ERP product processes will differ from the processes that are part of your organization’s “as-is” profile. Conscious and well thought out management decisions need to be made to decide: a) if processes in the organization are to be altered to match the processes supported by the tool; b) if the processes inherent in the tool will be changed by customizing the tool to match the business environment or, c) both the tool and the businesses’ processes will be changed to “meet in the middle.”

In many situations the process modeling work effort can be perceived as a waste of time and simply slowing the project down. In reality; performing effective process modeling will enable the project to run more smoothly by identifying problem areas up-front and ensures the overall success that the product that is ultimately delivered to the business will truly meet their needs.

Let’s examine one more project hazard that requires the project manager to be a hurdle…

Projects with unavailable project customers

When the definition and approach derived for a project isn’t the problem, it is often a lack of qualified, knowledgeable business personnel. This issue manifests itself with everything from the “you should know what I want” approach from project customers, to a blatant absence of project customers in project proceedings because they are “too busy.” This causes project managers to try to proceed with a significant handicap. A large portion of the project management community try to “press on” in this situation despite the lack of customer participation, surmising – inaccurately – that the organization will be better off if they at least create “something” for a project deliverable. The actual results are usually catastrophic; skeptical project team members that do not trust the product they are creating, a totally alienated customer that receives a product for which they feel no ownership, and a sponsor with a lack of confidence in the product and project management because of “poor” delivery.

Because these disastrous results are inevitable when knowledgeable business representatives are not part of the project, the only real way to respond in a situation like this is to become the ultimate hurdle and recommend the project be stopped until appropriate business personnel can be leveraged. This recommendation will bring a significant amount of attention to the situation which is exactly what you need to solve the problem!

When a project manager escalates due to lack of business resources, a business representative that doesn’t have the appropriate level of experience will sometimes be assigned to assist the project team. In short, they can’t successfully speak for their peers, or the process area they represent. Moving forward with these partially-knowledgeable individuals is just a nicer looking path to the same terrible conclusion. The project should be stopped until this situation can be rectified.

So, as project managers we are most often looked upon to eliminate hurdles, and drive projects to success. Sometimes however, it is most suitable that we become a “hurdle” instead, and ultimately help the project – and our sponsoring businesses – be successful in the end.

If you knew that 85-90% of all the work doctors did fail, how would you go about choosing your doctor?

What criteria would you apply? ……..

• their qualifications,
• letters after their name,
• associations,
• memberships,
• reputation,
• recommendations (hey I have this great doctor and he only fails 50% of the time which is well below average!).

So, if we wouldn’t accept these failure rates from our doctors, why are we still accepting them from those who manage our projects.  Not all of them of course, but the scary thing about these statistics is that they come from recent research on project failure rates.  That is, 85-90% projects are still failing to deliver on time, on budget and to the quality of performance expected.  Even if you disagree with the statistics, have different criteria you use for what constitutes a failure, or believe you can’t blame only the project lead, then what would be acceptable?  Think back to choosing your doctor; 50% failure, 25%, 10%……5%?

We think a lot about this at Mindavation, not which doctor to choose, but why project success rates are still low.  We think about this because we are passionate advocates of the art and science of project management. We believe that project management is at the heart of the way work is done in modern organizations and drives organizational success.

We know first-hand, and we are sure you do too, the positive impact great project management has on delivering maximum value to an organization.

So………, then the question is, what is getting in the way success?

Well, according to recent research published by the Standish Group and gantthead.com contributors the top three reasons for project failure are:

1. unclear scope requirements or change of scope requirements,
2. poor project management processes and
3. lack of executive sponsorship or management buy-in.

This might suggest the solution is straightforward; to develop these capabilities in project professionals.  However, we would argue that we already do.  We have some of the world’s leading professional accreditations and qualifications for project professionals in the world.

So………, then the question still remains, what is getting in the way of success?

At Mindavation, we know we are not alone in wanting the answer to this question and in fact, this topic has generated a great deal of discussion recently.

The common thread among these reasons for failure suggests that the low success rate of projects might partly be attributed to a lack of non-technical competencies, otherwise referred to as soft skills. Skills, that up until as recently as a decade ago were not considered fundamental to a project managers success.

So, as well as training for hard skills such as:

• Schedules
• Work breakdown structures
• Critical path diagrams
• Variance analysis
• Metrics
• Earned value
• Budgets
• Dashboards
• Risk management

It seems we should also be training for soft skills such as:

• Managing stakeholder expectations
• Leading
• Decision making
• Influencing Negotiations
• Resolving conflicts
• Problem-solving
• Motivating team members

We realize we are not the only ones to come to this conclusion, of course, but, what we have been doing is using this information and working with our clients to help them achieve noticeable improvements in their project’s success rate.

How?

By taking them and their project professionals through a customized development pathway which targets only the gaps.

For example:

Good project managers know who to create a WBS, so why re-train them in that? But, do they know how to communicate the information from the WBS to stakeholders in a way that ensures full engagement and commitment?

We have been working with our clients to help them answer these types of specific questions and help them design solutions that work for them. Ranging from Short Hits of Training (SHOT’s) for 2 hours, up to week-long programs including coaching and strategic problem-solving. For more information, feel free to reach us at info@mindavation.com and we’ll be happy to answer any questions!

Call for Action:

Meet the modern project manager: a triple threat who’s savvy in project management, business analysis, and change management. In this short course on LinkedIn Learning, you’ll understand how these three fields are coming together and reinventing project management to produce better business outcomes. Discover how they intertwine and help project managers deliver projects with clearer scope, tighter budget, and better results. For a short time only Triple-Threat Project Management is available for free access. You have free access from February 26 – March 2.

 

 

References

Frank Winters, (2003), Gantthead: The Top Ten Reasons Projects Fail (Part 7), Accessed: 21 January 2018. http://www.gantthead.com/article/1,1380,187449,00.html Gartner Group, (2000), Moderate Process

Rigor Is Faster (In the Long Run…), Conference Presentation. HCi Journal, (2001), Avoiding software development failure, Accessed: 18^th January 2018

http://www.hci.com.au/hcisite2/journal/Avoiding%20software%20development%20fa ilure.htm IT Cortex, (2003), Failure Rate – Statistics over IT projects failure rate, Accessed:21^st January 2018

http://www.it-cortex.com/Stat_Failure_Rate.htm KPMG, (2003), KPMG‟s International 2002-2003 Programme Management Survey, Accessed: 18^th January 2018

http://www.kpmg.com.au/content/Services/Services/Audit_and_Risk_Advisory/Information_Risk_Management/docs/irmprm_pm-survey2003.pdf Parliamentary Office of Science and Technology, (2003).

Government IT Projects the Standish Group, (1994), The CHAOS Report, Accessed: 21^st January 2018

http://www.standishgroup.com/sample_research/chaos_1994_1.php Toney Sisk, (2004), The History of Project Management, Accessed: 18^th January 2018

http://www.projmgr.org/PMHistory.pdf 2003 Report on Public Sector Agencies – Implementation of RMIT University’s Academic Management System, Accessed 18^th January 2018.

Arcidiacono, Giuseppe, 2017, Comparative research about high failure rate of IT projects and opportunities to improve. PM World Journal. Vol. 6 Issue 2, p1-10. 10p.

You have assembled a highly skilled technical team. After a long search, you have hired an experienced project manager to ensure the project is tightly controlled. Through careful budgeting, you ensure that appropriate funding is available. Do you think you have mixed a recipe for a successful project? Think again – a primary factor that may determine the success or failure of your project is your corporate culture.

Can corporate culture really make that much difference? Think back to the last time you tried to request a special service from – or implement a change in – an organization that embraces processes it has used for years. Did you get very far? Project management professionals can face the same type of resistance to change if they are working with an organization that does not embrace change as part of its culture. As projects are intended to bring about some form of change – a new product or improvement to an existing product, new processes, or enhanced tools – projects are especially threatening to an organization whose culture won’t embrace the transformation brought about by the project’s product.

Should you find yourself in a position where you face these challenges, the following are a few tips to help guide the project manager through this labyrinth of cultural tradition and emotion.

Introducing New Ideas

Although organizations vary in their acceptance of new ideas, concepts and approaches, each culture usually has a means by which new ideas can be incorporated into the mainstream workings of the organization. The introduction of new ideas is usually accepted when they originate from specific trusted individuals or from senior management. The astute project manager will work with the project sponsor to understand what type of ideas or changes they have introduced into the environment, along with the challenges they had to overcome along the pathway to implementation. In addition, conversations with the project sponsor about others who have successfully introduced change to the environment can be beneficial. Creating processes as part of your communication plan to make allies of these individuals can help significantly as your projects move through requirements formulation to implementation.

Acceptance Process for Change

How does your customers’ corporate culture accept new ideas for development and implementation? Many organizations embrace new ideas and have standard processes by which new ideas are spawned and tested. Republic Financial Corporation CEO, Jim Possehl, stresses their process of “Team Storming” to foster and evaluate new ideas. “Managers take their stripes off. Anyone can be critical of anyone else – everyone is treated equally. It is all about the ideas we have to improve our business.” The Team Storming process is for real – employees at all levels of the company are encouraged to generate and support new concepts for improving Republic’s services and image in the marketplace. Possehl uses the process as a great “organizational equalizer”; line employees openly question ideas surfaced by senior management with the same vigor as the managers question new ideas from their employees. “It makes for a very dynamic and trusting workplace,” states Possehl.

On the opposite end of the spectrum, some companies only consider ideas that have come through certain channels within the company such as marketing or other areas with a specific mission to drive change within the company. These organizations usually require screening processes to have been executed, such as market evaluations or comparative data analysis, before changes are considered.

As a project manager, researching what the acceptance process is for your customer’s organization can be instrumental to ensuring your project proceeds smoothly. In the first example stated here, no project would progress very far without the requirements and final solution having been through a “team storming” exercise involving a wide variety of employees and managers. Conversely, no project would be successful in the second scenario without obtaining the support of the organizational areas that normally sponsor change.

Acceptance of risks

Organizations vary widely in the degree of risk aversion that is inherent in their culture. This can be a product of the individuals at the top of the organizational pyramid, or could be a product of the industry itself. High-technology industries are more likely to engage in risk than a more traditional industry like insurance. In addition, aversion to risk can vary widely based on the type of risk being considered. In a very competitive area where major industry players are “leap-frogging” each other such as chip development, risk elements that prolong the time required to complete a project would be avoided at almost all cost. Conversely, a businessperson that is working in an area where price is the highest competitive factor will have difficulty accepting risks that affect project cost.

What is being discussed here is not only balancing the triple constraints (time, resources and scope), but also prioritizing them and understanding the magnitude of flexibility that exists within the triple constraints. Each organizational culture and the environment in which they operate will determine the flexibility allowed, and in turn will determine how much and what type of risk they will accept. Finding this through interviews, the examination of past projects and using carefully placed questions with key stakeholders can help the project manager navigate the areas where the organization will accept risk when planning and executing your projects.

Prioritization – Continuity in ImplementingChange

Most all organizations have some form of prioritization scheme that determines what projects are funded through to implementation, which projects are candidates for cancellation during execution, and which may not even be funded in the first place. Many project managers benefit from working within an environment where the prioritization scheme is well defined, is accepted and followed by the management team. Others have to work their way through prioritization systems that aren’t as well defined – some to the degree that project prioritization is more or less a random set of decisions made by a single manager, or series of managers, each with their own budgets.

Understanding the prioritization scheme (or lack thereof) can be useful for the project manager. Does your sponsor have the authority to make project prioritization decisions? If so, what are the most important business goals to that sponsor? If your sponsor doesn’t directly make prioritization decisions, does he/she know what the current considerations are for making prioritization decisions?

Knowing this information can be vital to a project’s ongoing survival, and can be used to further the cause of the project. Project status reports, milestone items, and interim deliverables can be set (or potentially changed during the course of the project) to keep in alignment with the prioritization scheme at any given time. Keeping track of the prioritization and modifying your project management approach (within reason) to conform to important business considerations can mean the difference between a successful installation and a sudden search for a new project to tackle.

Understanding corporate culture can be a difficult but necessary part of a project manager’s daily business. As a project manager, if you’re able to understand how ideas are introduced to the business, how change is accommodated, what type of risks are tolerated and which aren’t, and how and by whom business initiatives are prioritized, you will be able to significantly increase your chances of delivering projects successfully.

In past articles, canine knowledge has provided us with insights to project management as a whole and helped us navigate the world of business analysis. We will now take a look at how our faithful friends can teach us about project sponsorship. Effective sponsorship is critical to the success of a project – and certain characteristics show up consistently with good project sponsors. 

Dogs constantly demonstrate their priorities, care for what is important to them, and always find time for the things that matter. Sounds like a good sponsor, doesn’t it? So, once again, through extensive empirical research, interactive testing and a number of years of direct observation, compiled below are the “best of the best” techniques for project sponsorship I have learned from my dog. Open your mind, reflect on the dogs you have encountered and see if you can learn from these canine traits as well…

Completely enjoy and guard your bone

A valuable project brings change to an organization, however, change is difficult. Good project sponsors understand the difficulties these changes may bring, along with the benefits. They prepare themselves for the benefits, are enthusiastic about them, and participate in the process of assimilating change. Understanding their priorities and the priorities of the business they serve, the sponsor will guard their “bone” (the appropriately prioritized project) and embrace the process of change that is brought about by the project. This acceptance and participation in the change along with the people who must work through procedural and tool changes helps significantly in ensuring that project deliverables bring the business value that is intended.

Know where the snacks are – and how to get them!

A good sponsor, like most any loyal dog, will know where the “snacks” (funding) are, and will know how – and under what circumstances – they can get them. Just like dogs, they won’t always get them when they ask for them, but they understand how to be persistent to coax that valuable morsel out of the cabinet. This persistence is a learned process, refined over time. Good sponsors will know what approaches work, and with whom, and how aggressive to be to get the funding they need when they need it. The techniques change from person to person, depending on the personality of the people involved, and the business conditions. I think sponsors can learn a lot from dogs in this area. I’ve seen some very creative quiet “discussion”, gleeful dances, nudges and also some direct asking approaches employed by dogs that would put many sponsor’s efforts to shame (especially given the success rate for the dogs!)

There’s a time to play, a spot for the best ride in the car, and if I only could, I’d drive to PetSmart myself!

Dogs fully understand what happens when, and they have the patience to learn what works and what doesn’t. They know where they want to be, and where things won’t go so well for them. In short, they understand the processes that make up their world. Good sponsors demonstrate the same characteristic. Although they rarely execute their area’s business processes themselves (it might be as disastrous as having the dog drive to PetSmart!) they understand the processes and their benefits. Making changes to those processes – which projects certainly do on a regular basis – will have an impact. The good sponsor understands what those process changes mean, and can react appropriately.

Thoroughly and enthusiastically check out anyone that is coming or going

Dogs have a tremendous knack for knowing when any change happens around them. They will check out new furniture, “test” anyone that comes into the house, and ensure that nobody leaves without some acknowledgment. Diligent project sponsors will assist a project manager by conveying any changes to priority, business direction or the positions of senior leaders that might not be immediately apparent to the project manager. In short, they take the time from what they might be doing to “check out anyone that is coming or going” and therefore might have an effect on the project or its outcome.

Protect your territory with exuberance

Dogs know their boundaries, search the scope of their territory, and protect their turf from intruders or anything that might disrupt their lives or the lives of their masters. Effective sponsors do something similar – they understand the required scope of the projects they champion, and will only endorse changes to the project that are driven by legitimate business needs.

When the leash comes out, head to the door

Dogs know when to react – and they react to certain events or circumstances with great consistency. They are predictable to their masters. Good sponsors display the same trend towards consistency – they react in a similar manner when circumstances warrant their attention, and the actions they take are predictable (and might even have been discussed ahead of time). Whether it is risk coming towards fruition, a change in the “red-yellow-green” status of the project they sponsor, or business issues that may affect the project, their reactions are in line with prior project discussions or converge with details that have been placed in risk management or other control plans.

Know the power of wagging your tail and the occasional growl

Communication of needs and wants is a specialty of the dogs that have been part of my life. Tail wagging, barks of various pitch and very obvious body language convey their mood and disposition very plainly. Sponsorship involves communication interventions as well; when project priorities are being compromised, resources are being diverted inappropriately or business partners aren’t executing their responsibilities. Project managers will often need the support and intervention of an engaged sponsor to protect the project from the various distractions that can reduce the probability of project success. Under these circumstances, communication from the sponsor needs to be plain, direct and easily understood. A little growl now and then can go a long way! A great sponsor will also demonstrate a “wag of the tail” when the team does a super job!

Run to get a scratch or be petted

Dogs demonstrate one thing consistently – they go quickly and instantly to what is important to them. Food, attention or a chance to play will cause even the most “low key” dogs to abandon what they are doing. They know their priorities and ACT in concert with them. Effective sponsors display this tendency as well. Items that threaten the project will cause an interruption to a calendar, but good sponsors will protect their projects – saving the integrity of their project and objectives in the long run. They also ACT in concert with their words about project priorities in conjunction with the other activities in their business area. This doesn’t always mean putting the project first – at times that is not the best business decision – but decisions are made in harmony with stated objectives and priorities.

Always care, and show it!

Play and show enthusiasm – wag your tail or approach slowly when people seem sad – jump and be gleeful when something good happens – this is the world of expressive pets. We know what they want, we see what they are expressing – there is very little question about that. Effective sponsors are engaged and express themselves clearly. The business objectives of the project are clearly articulated, and the constraints that exist for the sponsor – and therefore the project – are defined and managed. They care about the business and the project, and demonstrate it through their actions and decisions.

Take a petting, give a kiss or two

Dogs are good at consistently exercising a give and take relationship. They don’t hesitate to come by to get attention, and they give love freely. Good sponsors provide support for the project, and coach the project manager and project team. At the same time they will define what they want to receive from the project and skillfully and constantly manage to that end. They receive business benefits because they manage the project environment, and they recognize the project team that brings those benefits to fruition.

It is a well documented fact – project managers are the tone setters for their project teams. The mood of a project team will be a direct reflection of the mood the project manager carries while strolling the halls, facilitating meetings and conducting one-on-one sessions with project team members. If you doubt this, try this test: tomorrow morning when you go into your workplace and make your way to your desk – look worried. Be assured, your entire project team will hear of this before midmorning and they will all worry, they won’t know what they are worried about, but they will most certainly worry!

Team building is a critical part of the role a project manager must fulfill to move projects to a successful completion. Many project managers however, view team building as taking the project team to navigate a “ropes course” or other form of intense experience that “bonds” the team. Although this type of experience does have its place in promoting positive team dynamics, most project managers don’t have the finances or the time to take their project team through such an experience. That being said, how does the project manager perform the critical function of team building? The following are a few suggestions for team building activities that can become part of your “everyday team building strategy”:

The Kickoff Meeting – Anytime the project manager has the opportunity to get his/her entire team together is a distinct opportunity to inject team building items into an agenda. The kickoff meeting is the first – and in many ways the most significant – opportunity to boost the morale of your team. Arranging a contest to derive a team name, providing an opportunity for a senior management level sponsor to address and encourage the team or organizing games or other activities that bond the team (or sub-teams) on your project can work wonders for encouraging employees. Chili cook-offs, best dessert contests, or carnival like games (I am personally fond of “Nerf basketball” free throw contests, and marshmallow sculpture competitions) are inexpensive, fun and bring the team together, without risking rope burns!

Weekly Status Meetings – Although many status meetings do not involve the entire project team, status meetings are also great opportunities to boost enthusiasm. Recognition of consecutive periods of “all targets met” status reports, the deft handling of a sensitive customer situation, or a technical idea that moves the project forward can be acknowledged with food, celebratory balloons or flowers, or a small gift certificate. Teams that are consistently meeting goals on a regular basis can be treated to a pizza party or other relatively inexpensive event. Even in cash strapped organizations, many people will still feel a sense of pride when a pizza event is celebrated by a manager allowing the team to meet outside of work and eat pizza they have paid for themselves! The publicity, recognition of a job well done, and the creation of an event that is not part of “everyday office life” are more powerful a motivator than most project managers realize.

Milestone Achievement – When a milestone is achieved – significant or not – the project manager is compelled to recognize the event and single out the individual or team’s accomplishment. Even in cases where the milestone was achieved late or over budget, a respectful acknowledgment of the obstacles overcome and/or the lessons learned can take a team out of the doldrums and into a more productive mode. Many of the small (but significant) celebrations discussed above as part of the weekly status meetings would be applicable here as well. For longer projects, the creation of milestones for the sole purpose of recognizing the team can be instrumental in maintaining morale and momentum for the project. For example, if you are managing an 18,000 task, 20-month project, creating a milestone at the halfway point – after the 9,000th task for instance, provides a catalyst for celebration.

Bringing in a sponsor to sincerely discuss what has been accomplished, discuss the enduring need for project deliverables, thank the team for it’s efforts, and encourage continued performance (along with other team building activities similar to the kickoff meeting) will serve to renew a team’s energy and sense of purpose.

Day-to-day Conversations – The project manager that makes an effort to have one-on-one conversations with project team members on both a business and personal level, can boost the esteem of individuals and the team as a whole. There are two pivotal questions that can be posed to team members to enhance a sense of belonging and purpose: “What does this project mean to our customer?” and “What does this project mean to you?”. A project manager that poses these questions and carefully listens to the answers can accomplish a lot with her/his team members including: a reflection of genuine purpose for the project and the need for the individual to be part of the solution; an affirmation of the appropriate understanding of the customer needs (or an expansion of the PM’s perception of the customers needs!), and a genuine sense of concern for the employee by management. Working to boost the feelings of well being in each employee will increase the probability of creating a high-performance team.

Informal Team Meetings – Project managers that follow the Management By Walking Around (MBWA) approach can engage in conversations with team members and gather folks together to quickly disperse information, collect opinions, and solve small problems. The project manager that works this way can realize many advantages – their team members feel their opinions count, team members get a sense their project manager is available and accessible, and problems can get solved before they start to grind energy out of the team. Often, the information exchanged at an “agenda-less” informal conversation can empower team members and keep the project manager informed in real-time. This helps a team perform well, and performing well boosts team morale.

Final Contribution Summaries – The celebration of delivery and acceptance of the final deliverable can solidify the sense of pride and accomplishment within the team and cause the memories of working on the project to be positive one. This will help the project manager when working with these team members in the future. More important however, a project manager who is diligent about documenting a one or two paragraph summary of the contributions of each team member and sending that to the team members management team will earn a loyal team member for future projects – and bring the project manager a step closer to having a team with high morale before a new project even starts.

So, team building is not about AN event, it is about a series of small instances that are positively exploited by a project manager who is mindful of his/her team. So, when you go into work tomorrow, don’t tie yourself up in knots thinking about the expense of a ropes course, just order a pizza, put a smile on your face and walk the halls. You’ll see a difference in your team very quickly!