Skip to main content

Tag: Business Analysis

From the Sponsor’s Desk – The Risk of Unintended Consequences

Written by Drew Davison on . Posted in Articles. 1 Comment on From the Sponsor’s Desk – The Risk of Unintended Consequences






Sometimes, the best of intentions results in unanticipated, and undesired, consequences. The French economic journalist Frédéric Bastiat wrote in his essay “What Is Seen and What Is Not Seen”: There is only one difference between a bad economist and a good one: the bad economist confines himself to the visible effect; the good economist takes into account both the effect that can be seen and those effects that must be foreseen.

I would argue that the same observation applies to managers. The bad ones concern themselves with the obvious, visible results. The good ones identify and deal with both the visible and the potential, positive and negative.

In this post, we’ll look at an organization that experienced the departure of a talented and respected leader and the actions taken by the CIO to plug the gap. He addressed the obvious, visible needs but failed to consider the ramifications of the leader’s departure and the affect this would have on the organization and its customers. The CIO experienced the risk of unintended consequences first hand.

Thanks to L.S. for his contributions in this case.

The Situation

This company manufactured communications equipment and software for the business and consumer markets worldwide. In the early 2000s, they had experienced a drop in sales, revenues, and repeat business because of poor quality across their product lines. To address the issue, the CIO hired a talented engineer as Quality Assurance Director. In addition to being a talented engineer, the Quality Assurance Director (let’s call him the QAD for short), was an engaging and insightful leader. He had a passion for the power of collaboration to solve tough challenges. He was an energizing communicator and had the ability to get individuals and groups motivated to achieve difficult goals.

It took the QAD less than two years to build an organization, return quality results to their previous levels, and start to compete with the industry’s best. Due to his efforts, “Build Quality In” was at the core of the company’s culture, in all product lines. And then the QAD resigned. He had been offered a vice president position with a company in another industry. The CIO was unable to compete.

The Goal

The CIO had an immediate challenge to fill the QA Director vacancy to maintain and advance the company’s quality track record.

The Project

The CIO met with the Human Resources VP to begin the search for the QA replacement. The list of qualifications included appropriate engineering designations, senior management experience, quality control/assurance experience, and industry/product line exposure. The CIO identified one potential candidate internally, a Quality Control Manager responsible for one of the product lines. She had been recruited and mentored by the departing QA.

The candidate search commenced with screening performed by Human Resources staff. Eleven applicants were selected for the interview stage, including the one internal candidate. Interviews were conducted using a behavioral interviewing approach with a standard set of questions. Interviewers included the CIO, VP of Engineering Services, and three product line managers.

The interviewers summarized their findings after each interview with both objective and subjective ratings. These results were brought together by Human Resources staff and tabulated to arrive at ranking for each candidate.

The Results

The CIO decided to promote the internal candidate even though she was ranked eighth of the eleven candidates interviewed. He reasoned that she was a known quantity who could get up to speed quickly. He thought she presented the lowest risk. She was respected by her staff and well known by the staff she would have reporting to her. As well, she was familiar with the managers and executives in the business organization. To the CIO, it looked like a no-brainer.

Unfortunately, the CIO promoted a good mid-level manager to a job that required stellar leadership talent. The newly appointed QAD was not a strong leader, not a natural communicator, not an inquisitive visionary, all attributes that were essential to move the organization forward.

In her previous role as a Quality Control Manager for one of the product lines, she had demonstrated mastery of the products and the processes and practices used to design and build them. She was able to work closely with the product engineers to improve quality and move the threshold forward. She was tenacious in pursuing her goals and rigorous in the application of company policy. These were the characteristics that convinced the CIO she was right for the QAD job.

{module ad 300×100 Large mobile}

What the CIO didn’t recognize, however, was that she followed the path laid out by her former leader. The CIO didn’t understand that she had limited exposure working with senior managers, that she had no experience setting and selling a vision. She had limited experience mentoring staff or building and managing the transformation of a vital corporate function.

In addition, the CIO assumed that she was fully ready for the director role and spent very little time with her as she transitioned into the new job. As a result, she continued to operate as she had in her previous manager role. She didn’t build the requisite relationships with the company’s senior management, customers, engineers and staff supporting other product lines.

The danger signs surfaced soon after her appointment to the QAD role. Two of the twenty staff in her organization had been seconded to product line organizations by the former leader. He believed the more they understood the products and the people making them, the better his organization could serve their customers’ quality needs. When the seconded staff’s stints were up, they chose to stay in the product line groups rather than return to the QA organization.

Word began to filter out that the new QAD was a control freak. She tried to micro manage everything. She applied company policy to the letter of the law. Where the previous QAD had allowed some staff to work flexible hours because of the nature of their current assignments and personal life challenges, the new QAD insisted on compliance with formal company hours, no exceptions.

QA staff started to leave the organization. They claimed they didn’t know where the group was going. It wasn’t fun or exciting anymore. There were no more “all staff conflabs”. The previous mandatory daily fifteen minutes scrums that were free-flowing exchanges of information had turned into interrogations by the new QAD. Where all product line quality practices and results were once shared with all QA staff, the new QAD insisted that staff focus on their own product lines. There was no more sharing.

As staff departed, the new QAD was challenged to fill the gaps. She made some bad hiring decisions which demanded more of her time, took her away from other priority duties, and exacerbated the performance challenges her organization, and the company were experiencing. The CIO began to get demands from his colleagues to fix the QA problems.
After thirteen months on the job, the new QAD was let go. The CIO returned to the list of interviewed candidates and managed to hire the number two candidate to turn the quality performance around.

How a Great Leader Could Have Delivered

As they say, the road to hell is paved with good intentions. Fools rush in where wise men never go. There are too many sayings describing the risk of unintended consequences for it to be an occasional occurrence. This CIO fell into the trap as well. He jumped at what seemed an obvious choice without weighing the reasons behind his candidate’s eight place ranking. He had well-founded due diligence in his grasp, and he ignored it. What could he have done differently to produce a better outcome?

• Evidence-based decisions

He needed to use the interview ranking results, not ignore them. If he was going to select the eighth-ranked candidate, he had to at least rationalize the reasons for the ranking and build a plan to plug the gaps that were revealed. There were also four other individuals involved in the interviewing process who should have had an opportunity to explain their views on the candidates.

• Use your network

The new QAD was known to many in the organization in her previous role as Quality Control Manager. The CIO could have used that network to solicit informal feedback on the candidate and her potential for performing the director’s job. He could have also reached out to the former QAD. Had he done so, he would have been told that the Quality Control Manager was not yet ready for the director’s job for the reasons that soon became apparent. Also, once the new QAD was appointed, the CIO should have maintained those contacts to solicit feedback on her performance. That would have provided an early warning of the difficulties she was encountering.

• Mentor

Having made the decision, the CIO needed to mentor the new QAD to help her transition to the new role as quickly as possible. A mentoring relationship would have provided the CIO with essential insight into his new director’s capabilities and development needs and the follow-on actions necessary to help her succeed.

• Progress metrics

Replacing a successful leader of a vital organizational function is a significant organizational change. The change effort should have been accompanied by appropriate goals and metrics and tracking, reporting and review processes to ensure the company was still well served, and the incumbent was performing to expectations. That didn’t happen. The new QAD and the CIO paid the price.

As managers, we’re often pressed for time to deal with pressing challenges and make appropriate decisions. How often do we jump to the most obvious decision? Sometimes, that works out, but often it comes back to haunt us. Resist that temptation on the knee jerk reaction. Please take the time to consider the options to avoid the risk of unintended consequences. If you find yourself in a similar situation, put these points on your checklist of things to do in future endeavours so you too can be a Great Leader. And remember, use Project Pre-Check’s three building blocks covering the key stakeholder group, the decision management process and Decision Framework best practices right up front so you don’t overlook these key success factors.

Finally, thanks to everyone who has willingly shared your experiences for presentation in this blog. Everyone benefits. First-time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details, and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights. Thanks.

Leadership Lessons: Implementing Change – Phase 4 – Create Desire to Change

Written by Peter de Jager on . Posted in Articles. 2 Comments on Leadership Lessons: Implementing Change – Phase 4 – Create Desire to Change

Editor’s note: We will be showcasing each phase of Peter de Jager’s methodology in weekly posts. Click here for phase 1, phase 2, and phase 3. Check back every week to read the next phase.

“A body at rest will remain at rest until acted upon by an outside force.”

That’s as much an observation about people as it is about physics. If there are no outside forces, then nothing changes. Sometimes the ‘key’ to change is nothing more than making people aware of the outside forces. One of the downsides of the status quo is that it lulls us into a false sense of security and we need to be shaken awake in order to change.

What Problems exist in Status Quo?

Nothing is ever perfect, that includes the current status quo. The imperfections in the status quo, create points of leverage that can help move a change forward. What is it about the current situation that has been a well known hindrance in the past? How dissatisfied is the target audience with the status quo? What exactly causes that dissatisfaction? If you don’t know the answer, ask the target audience –  they do, in great, exacting, painful detail.

What are the alternatives?

What alternatives are there to the current status quo? There is always more than one way to do things. Why did we choose this particular status quo? What other options did we have? What other options can we create? Does it really matter, in the long run, which option we choose? If not, if they are all relatively equal, why can’t the target audience choose which one they should move to?

What are personal Benefits to Changing?

Just as there are always problems with the current status quo, there will also be benefits in any new situation. It’s a useful exercise to help the target audience to list those personal benefits.

What problems would Change Solve?

Will the change being proposed solve existing problems? How? If not, why not? It is a mistake to think everyone involved in the change sees all the benefits of the change. It’s perhaps a tedious task to list the benefits, it’s also very beneficial to those who may not fully understand all the implications of the change. It’s difficult to communicate enough during change; it’s impossible to communicate ‘too much’.

What core values would Change reinforce?

What, out of everything the current status quo provides, will be reinforced by the proposed change? This is another way of communicating what will stay the same, only more so. This is surprisingly, a very powerful bit of information. People need stability, and knowing what won’t change in the coming months will offer more solace in the face of chaos than you might expect.

What opportunities would Change Create?

Change is not just about escaping problems in the existing status quo. It should also be about creating an environment of new opportunities. Do not assume the target audience can see those opportunities without being told, informed, communicated to etc. The primary task of the Change Inflictor is one of a communicator. Informing and re-informing people of what is going on and why.

© 2015 Peter de Jager – Reprinted with Permission

Forecasting: Is it EVIL in Agile Portfolios?

Written by Robert Galen on . Posted in Articles. 1 Comment on Forecasting: Is it EVIL in Agile Portfolios?

I’m often quite wordy in my blogs. I’ll pose an initial question in the title, throw out a thousand words or so, and then present a conclusion. I’m not going to do that here. Instead, I’ll be much more succinct.

IS FORECASTING EVIL IN AGILE PORTFOLIOS?

YES!

The context for this conclusion and subsequent discussion is three-fold:

1. Forecasting when you are just building your Agile teams OR are in the early stages of an Agile transformation;

2. And, when you’ve been doing Agile for awhile, and you’ve become overconfident with your capacity awareness;

3. And forecasting in this sense is anyone determining how large or how long something will take and NOT fully engaging their team in the estimation, planning, and forecasting.

Let me be clear, in my experience this IS the way traditional projects have been forecast.

Usually, a small group of product folks will get together with technical managers, a project manager, architects and perhaps a technical team lead or two. Often QA and other functional team representation are left out of the mix, with the thinking being that the developers can estimate “for” them. The product folks present an “ask” to this small team and they estimate the LOE (Level-of-Effort) associated with the functionality. If it’s a Waterfall project, then who (# of Dev, QA, etc.), how long (days, weeks, months, transitions or workflow, etc.), and output (lines of code or components, tests, documents, etc.) are the usual units of estimation.

In Agile contexts, the same things occur. However, the estimation units usually change to be specific numbers of small Agile teams, velocity or capacity, and number of iterations.

To be even more clear, these folks are not destined to do the work. But they set an expectation for the work and then go back to whatever their day job is. At some point the “ask”, if the cost and ROI are deemed worthwhile, is handed off to a set of teams to deliver. Often, the view is that the “hard work” has already been done, and there is simply “execution” left for the teams.

MY KEY PROBLEM

My key problem with all of this is that someone else is estimating for, and let’s be real here – committing for, the teams. I know, I know, there are many excuses – I mean reasons for it. Here are some I often hear:

1. The team is working on something important right now. We simply don’t have the time to interrupt them to estimate another project. And it would COST too much to do that as well. What we’ll do is select a small set of high-skill team members to do the pre-work before we get the entire team engaged.

2. This project is WAY too BIG to get everyone together. We do Enterprise-level projects around here. We have large numbers of teams AND many of them are distributed around the world. There’s just no way that we can get EVERYONE together.

3. This project has new technologies and new approaches intended. The team doesn’t have a clue about this. But Bob, the architect does. We’ll get Bob and his team to “iron out” the hard-bits in advance of the team’s execution. Bob can even run some “Lunch & Learns” as a way of passing off technical knowledge in the beginning.

4. We’re trying to prioritize our entire PORTFOLIO right now and we need high-level LOE estimates to do that. So there’s no way we can ask the entire team to estimate 10-15 major initiatives. Of course, we’ll give each team the opportunity to pull together a more realistic estimate before we start execution.

Now there is validity to all of these points. I truly understand the balance in getting things done (current project work) versus planning and forecasting (determining future capacity). But if our goal is to forecast accurately and best understand our projects, then I still feel the best way to do that is to engage as much of our team targeted towards the work, as early as possible, so that we get the most realistic estimates.

Here are five reasons that engaging your teams is the best way to forecast. It’s not all-inclusive but simply intended to show the “why” behind my recommendation that forecasting is evil IF you don’t engage your teams in the effort.

5 REASONS TO ENGAGE YOUR AGILE TEAMS IN FORECASTING

Velocity is a fragile thing

First of all, anyone who is using velocity as a measure of his or her Agile team’s output or performance must realize that it’s a fragile thing indeed. Beyond not wanting to compare it across teams, there are simply so many factors that can influence velocity. For example, illness, attrition, interruptions, multi-tasking, skill, team maturity, and co-location are just a sample of the factors.

I’m not saying not to use it. I consider it quite a valuable metric. It’s just that you need to consider it within the context of each team and not over or under react to sudden changes in velocity. If we include the teams in the planning mix, they’ll take a more reasoned approach to estimating their velocity AND the possible variations they might experience due to “external forces”.

TEAM COHESION MATTERS

I’ve found that teams take quite a long time to come together and to become truly cohesive as a team. Once formed, they are incredibly capable. But if you start nit-picking teams members away for special projects or higher priority interruptions, then you undermine the capability of the entire team.

Often in our traditional forecasting we ignore the real world of multi-tasking, project interruptions, focus factors, customer support, and such. If we include our teams in the planning mix, they naturally include these factors.

Not that long ago I had someone ask me what was the ramp-up factor for a new Agile team? In other words, how many sprints would it take for a new team to become fully functional? They were looking for a magic number to plug into some spreadsheets as they did their forecasting.

My answer to them – there is no magic number for this AND you might want to ask your teams. While I felt it was the correct answer, I don’t think they appreciated it.

PEOPLE OR NOT “RESOURCES”, THEY’RE NOT FUNGIBLE

If you’re dealing with chairs or computers desktops, then I could see someone else forecasting the needs over the next few years as being reasonable. These are fungible resources and of course they can be forecast.

But are people (skills, collaboration, morale, ability to attract/hire, etc.) so easily handled? My broad experience tells me – no.

So if we include our teams in the planning mix, we’ll get a sense of the capabilities of the team that we’ve formed. We’ll find out if they have the equipment, tools, and training to do the job. We’ll find out how long it will take the team we’ve formed to do the job we’ve placed before them. They might even include real-world events like vacations and family events in the plans.

UNDER COMMIT AND OVER DELIVER

It’s incredibly easy for someone not doing the work to commit to an outcome. Often they’re quite optimistic about the LOE – maintaining a sunny day view to everything and not truly considering risks. I think it’s human nature. But there’s a reason that your building contractor not only estimates building your home, but they build it as well. Can you imagine if I was doing the estimation for your contractor?

Sure many of them come in “over schedule”, but I guarantee a terrible result if I’m doing the estimation for them.

If we include our teams in the high-level planning mix, we’ll get much more realistic plans that include risk and contingency. The other thing that always impacts our plans is cross-team and external dependencies. Again, teams can more realistically and broadly consider and plan for these.

When I do release planning (PSI – Potentially Shippable Increment planning for you SAFe folks) with Agile teams I’m coaching I often talk about discovering what I call “glue stories or glue work”. This is work that isn’t typically associated with a functional Feature or User Story, but it needs to be completed in order for the PSI or Release to be usable or considered complete. My experience is that ~40% of the work for a project/release/PSI usually surrounds this non-obvious or hidden work.

And only your teams can truly surface these risks, dependencies and hidden work in your plans. You ever wonder why most projects are over schedule? I think this is one of the major reasons for it.

SPEAK TRUTH ABOUT UNKNOWNS AND AMBIGUITY

In other words, be willing to say – “I don’t know”.

One of the things I’ve always found interesting when getting estimates from an “advisory team” as opposed to the eventual team themselves is that I rarely hear those magical words – I don’t know.

If you think it’s hard for a team member to admit this, it’s even harder for these more seasoned folks to admit their lack of specific knowledge and practical experience. But if you want to understand accurately your projects, then having this honest dialogue about unknowns and ambiguity as early as possible is exactly what you want.

And in my experience, teams doing planning will have a tendency to “Tell Truth” much more often than folks who have seniority or perceptions to worry about.

WRAPPING UP

Now that I think about it, do I have trouble with forecasting? Actually, no!

It’s the perceptions around it that are the problem, words like: commitment, fixed date and scope, customer expectations, and promises made for the teams. If you truly do forecasting as a high-level triangulation mechanism, but don’t believe/use those LOE estimates until the teams “make them their own”, then I’m perfectly fine with forecasting.

Scaled Agile Framework (SAFe) conceptually handles this quite nicely. It allows for ongoing portfolio and project-level planning. But there is NO COMMITMENT to a PSI or Release Train until the team gets the chance to break down the features into user stories and pull together their PSI plan (a response) to all of the higher level planning. Then they commit to the PSI and begin execution.

If the leaders and stakeholders planned for the team releasing 10 Features in this PSI, but the team only committed to 5, then those leaders and stakeholders should have made soft enough commitments so they can go back and reset them to 5. And they should also use that data-point of “5 feature velocity or capacity” to readjust their portfolio and project level forecasted plans.

Now that sounds easy in words, but in my experience the devil is in the details readjusting those initial “commitments”. And it’s not for the team to do. It’s for the leaders, stakeholders, architects, managers, product owners, and project managers to do. They are the ones “disconnected from reality”.

Stay Agile my friends,

Bob.

How Senior Executives Unconsciously Disrupt Projects

Written by George Pitagorsky on . Posted in Articles. 6 Comments on How Senior Executives Unconsciously Disrupt Projects

It is fairly common for project teams and operational units to have their planned work interrupted with ad hoc requests for information and emergency needs for new projects and changes.  As project managers, we know that it is difficult enough to provide a realistic plan and deliver quality results on time and budget without an uncontrolled flow of new or changed requirements from clients and sponsors.  

We have change control and keep track of the number of ad hoc requests to stabilize the environment and/or justify late and over budget projects.  Even so, ad hoc, emergency requests that must be responded to immediately are still disruptive.

In one organization (names withheld to protect the innocent and guilty) a large complex program to modernize business operations required that business unit staff attend requirements definition sessions, training events, and take part in testing.  There is a fairly constant flow of random questions from the corporate parent.  Each question requires research and response by the same subject matter experts who are also required to do their normal operational work and take part in improvement projects.  Subject matter experts (SMEs) cancel meetings, just don’t show up, and have their minds elsewhere when they do show up. 

Operational work is their highest priority, though, even that takes a back seat to responding to demands from above.  Project work is the lowest priority, even when the project is critical to the future health and growth of the organization.  Therefore, projects are delayed, project teams are frustrated with what seems to be a lack of interest, caring and discipline on the part of operational staff and management.  Operational staff are equally frustrated by being taken away from their work.  In the end, the project team takes the blame for not meeting deadlines and life goes on as usual.

This problem can be resolved with a concerted effort, courage, better planning, and persistence.  

Effort 

Track, collect metrics, analyze interruptions, and identify their causes.  Create increasingly robust inquiry and research capabilities to enable quick response by the requesters themselves, administrators or help desk people rather than operations and project people. Create or enhance the process to manage project initiation.

The effort is motivated by the understanding that 1) the requests will not go away, 2) it is unlikely that the people who make them will think ahead sufficiently to give the responders adequate time to respond in a non-disruptive way and 3) it is possible to improve the situation.  Once that is understood, then there is a need for a commitment to make a process change.  The first part of the change is to cultivate the disciplines, procedures and systems to identify, catalog, and analyze the interruptions.  Based on the results of the analysis, the action to address the situation can be planned and executed.  

That action might be the creation of an easy to use inquiry capability supported by a business data dictionary that enables access to data that has been “hidden” in operational databases and files. In many organizations, this is a heavy lift, requiring data analysis and the implementation of data management tools and procedures.  Take the effort to minimize the research and inquiry response time while getting project people out of the process.  Make the data available before it is required and give analysts and administrators, or even executives easy access to it.

Another kind of effort is also required. Create or fix the portfolio management and project initiation process so that interruptions and constant priority changes are brought to light and that their causes are known and addressed.

In other words proactively take control of the environment.

Courage

Since most interruptions come from above in the organization’s hierarchy, it takes courage to push back.   It is hard to say no to a senior executive who calls for a piece of information that they need for a meeting that is to take place in an hour.  The call sets off a scramble for data and then to the possibility that the data will be poorly presented, leading the executive in the wrong direction.  The courageous will inform the exec who does this chronically that they are disrupting operations and projects, risking misinformation and costing the organization money.  This is where metrics about the number and type of interruptions comes in handy.  

Emergency projects and changes are a bit easier to handle than requests for information, simply because the need is not as immediate and because they are more disruptive and more costly.  Here the courage and ability to provide quick feedback about just how disruptive and costly the change will be is important.  Often these requests come down from the executive’s staff.  Maybe, the exec’s request is nothing more than a nice-to-have misconstrued as an immediate need. It is important to get validation.  How?  By being clear about the impact making the change will have on existing projects, its cost, and the real duration.  Make sure the message actually gets to the executive.

Make the cost of unbridled inquiries and ad hoc changes clear to the executives and their staff.  Replace knee jerk reaction with a measured response in a reasonable amount of time.  Have the courage to push back.

Planning

The more you plan, the less courage you need.  The more effort you take to capture and analyze metrics, the easier planning is.

Skillful planning considers past performance.  Consider interruption time when scheduling.  It should be obvious by now to all project managers that when there has been a history of regular interruptions that they will probably continue.  It is quite possible to estimate the resource requirements for handling interruptions and take that into account when scheduling.  If twenty percent of the resources per month have been called upon to handle interruptions in the past, if nothing has been done to change that, then only schedule for eighty percent availability.  If, by some miracle, there are fewer interruptions than normal, you will come in ahead of schedule, which is much better in the eyes of just about everyone than coming in late.

If people complain about the lengthy schedule, explain why you are expecting the project to take longer than it should.  Be ready to show your metrics to back up your explanation.

Persistence

Don’t give up.  Keep pushing back, using your metrics to highlight the cost of interruptions and continue to recommend the projects that will reduce the burden on project and operational staff. The requests for information and the new ideas and needs for new projects will not go away.  But, through persistence, the effort to make them less disruptive can be authorized, planned and executed.

Project Leadership Remains #1 Key to Success

Written by Lisa Anderson on . Posted in Articles. 5 Comments on Project Leadership Remains #1 Key to Success

In thinking about the hundreds of client projects I’ve completed over the last ten years, if I had to pick one key to success, it would be project leadership. For example, I worked with one client on multiple projects simultaneously with several project leaders over the course of many months. The same senior leadership sponsored every project. A few were downright frustrating as we struggled to move an inch a week whereas others leaped forward a mile in the same timeframe. Of course my focus was to accelerate progress on the ones that inched forward; however, significant acceleration could go from an inch to 5 feet; still slow as molasses as compared with moving a mile.

While leading and/or participating with hundreds of projects with manufacturers and distributors across multiple industries, geographies and company sizes, several keys to project leadership success emerged. What successful leaders have in common is worth noting. Thus, it seems discussing top strategies for success would be of value. Instead of limiting it to the top 3, I thought I’d share a longer list that arose during observation.

1. Vision: As all executives know, having a vision is essential to success. What do you expect your project to accomplish? Why is that of value to the organization? How does it fit with strategy?

2. Communication: Having a vision does little for success if no one hears about the vision. Communication skills are essential. This is the bedrock for any leadership role. However, it tends to be even more critical on projects as the majority of team members might not report to the project leader for their day job and so communications might be limited.

3. Energy: It helps to have a project leader with energy. Being excited about what the project can achieve goes a long way to making the team interested in being a part of that objective. Demonstrate excitement through your tone of voice, language, through promotion, etc.

4. Competence: As effective a communicator you might be, it is still essential to be competent in the subject matter related to the project. There is no need to be an expert; however, you need to have a basic knowledge to be able to lead effectively.

5. Ability to ask questions: One of the keys to success is the project leader’s ability to ask good questions. I have worked with horrible project leaders who asked “stupid” questions – it was obvious to the team members that they weren’t capable and/or was annoying; thus, no matter what other qualities they had, their project progressed slowly at best. On the other hand, I’ve seen people with zero knowledge of engineering successfully lead a group of engineers by having enough knowledge or logic to ask a few good questions to keep the process moving.

6. Ability to think of the critical path: One of the most important aspects of project management is to know what is important to the success of the project. Not all tasks are created equal. In today’s busy world, there is rarely time to focus on all tasks to the desired degree; thus, focusing attention on what’s important is critical. The critical path will make it obvious which tasks should be the focus as they will hold up the rest of the project.

7. Ability to facilitate teamwork: It is important for the project leader to facilitate teamwork. Typically the project team might be from multiple disciplines/functions who might not know each other and who might be in conflict in terms of daily objectives. Thus, the project leader needs to facilitate the common objectives and find strengths to leverage while making all team members feel included in the process.

8. Ability to push back: The best of managers, when all is proceeding smoothly, can become the worst of leaders if a roadblock arises. It is critical for project leaders to be able to address issues head on in a respectful and proactive manner. This often requires pushing back on executives who might have conflicting interests. Turning it into the best interest of all parties helps the leader push back successfully.

9. Follow-up: No project is successful if follow-up is lacking. A key part of the process is being proactive about which tasks are coming up and making sure the task owners are ready and potential roadblocks are resolved. Checking in with the project team, sponsors, related / impacted employees and the like is key to success.

Since project leadership proves to be #1 to successfully achieving objectives, it is worth additional focus. Are you assigning whoever is available with some level of competence to your project as resources are scarce or are you carefully considering the options? Since the vast majority of cost improvement, new product introductions and the like are accomplished through projects, it is worth extra focus to ensure project leadership success as these results will impact growth, profit and cash flow.