Recently in Leadership Category

This is a guest post from Roger Chou, PgMP, of the Institute of Taiwan Project Management

Five years ago in Taiwan, there was a general lack of awareness about project management.

This led all of us in the project management community to some basic questions: How could we prove the value of professional project management teaching and qualifications to the country's leading opinion-makers? And how could we show that having as many qualified managers as possible would be good for business and therefore for society?

We decided to provide free project management training to business leaders, company managers, politicians and other influential people. All of these people knew enough about management skills and practices to take such an invitation seriously--and if it was free, how could they refuse?

In this way they would understand what all the Project Management Professional (PMP)® education providers were trying to achieve.

This became our strategy: influence the influential.

After getting first-hand experience of what it meant to be trained and to work as a professional project manager, participants started to endorse project management education and qualifications.

At the same time, we also facilitated numerous newspaper reports on major successful projects, including Taipei's Tower 101.

We also managed to get over 2,000 people--many of whom participated in the free training--to sign the petition for proper project management training sent to our main forum of elected politicians, the Legislative Yuan. Following this petition, we wrote an open letter to Taiwan's president about the importance of project management teaching and qualification.

One of the hardest places to introduce new ideas, practices, technology or anything that requires rethinking convention is within government departments. They see their main responsibility as implementing policy--discussions about or changes to working practices could be potentially costly distractions from an already sensitive process.

Despite the challenges, our efforts have paid off. As of January, all civil servants are now required to have professional project management training and qualifications.

While "influencing the influential" was a business plan specifically tailored to Taiwan's situation and needs at that time, we were nevertheless following our own professional management training.

As the A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) indicates, identifying your stakeholders and satisfying their needs would be the first step to successfully managing change, regardless or how big or small that change.

The last hypothetical I posted, Is This Your Project Stakeholder? attracted a wide cross section of responses.

It made me wonder what you think of this real life experience (only the names have been changed):

Sebastian is a highly competent, upwardly mobile executive and your boss. He works 6 a.m. to 10 p.m., and is a very detailed person. He proofreads everything, making copious corrections and is also studying for his second master's degree.

You have found the best time to approach Sebastian to discuss anything is after 8 p.m. when the office is quiet and he is working on his studies. In fact, at this time of night he seems to appreciate a brief chat.

The problem is you have a "life" outside of the office and feel 8 a.m. to 6 p.m. is a very fair day's work.

How would you approach building rapport with Sebastian to allow the discussion of important project issues and enhance your career prospects without waiting until after 8 p.m.?

I will review all comments and based on your feedback I will suggest some solutions in my next post.

In the book Peopleware by Tom DeMarco and Timothy Lister, there's a humorous story about a project manager who--seeing the progress her team was making--knew she would deliver her project on time. With confidence, this project manager told management that she could guarantee the project would come in, as scheduled, by 1 March.

Management chewed over this unexpected good news and summoned her the next day. They told her that since she was on target for 1 March, they were moving up the deadline to 15 January.
 
I had a similar experience when I presented an initial update for a recent software project. I confidently explained to our stakeholders that the software enhancements for the common process tool would be delivered on time.

Sheepishly believing the stakeholders would be impressed, I waited for a compliment. 

Instead, the stakeholders proceeded to hand down a "schedule challenge" for the team to deliver three weeks early. Their rationale was that they wanted to capitalize on the team's productivity and wow the senior leadership team.
 
So, care to share your productivity war stories? 

My last post received a wide range of comments and I wanted to draw some conclusions based on those comments and my thoughts.

The majority of those that left a response said they would choose "option one." If you selected "option one" and well managed your relationship development and engagement processes, then helping "Mary"--the stakeholder in question--and her team contribute to the change should be beneficial. Why?

The first thing to consider is that Mary would be a key stakeholder at several different levels in the overall change management program.

As a long-term employee leading a group of workers, she is a stakeholder in the overall organization and is likely to have many unofficial contacts and significant influence.

As the leader of a group of workers who will be disadvantaged by a planned reorganization, she and her team are critically important stakeholders for the change manager. The group will never like the consequences of the change, but they need to be included so they at least cooperate for the good of the overall organization.

Because they can contribute knowledge and support, Mary and her team are also stakeholders of the program and particularly your project. The assumption that your team has enough knowledge to bypass her people is risky. You don't know everything that happens in Mary's section on a day-to-day basis.

The second important consideration is where the value is created. Ultimately, there is no value to the organization unless the change is successfully implemented.

Your project may deliver a key component needed for the reorganization but if it is not used, there is no value. This is something IT people in particular need to remember; 99 percent of IT projects require changes to business processes and are a complete waste of time if the business people reject the new processes.

If you selected "option two" and chose to ignore Mary, she is likely to become an active opponent of the change (no involvement equals no commitment and no support). This puts your most important stakeholder at a disadvantage: the overall change manager.

Imagine for a moment your organization has decided on a major restructure, and as a consequence has initiated a change-management process and appointed a change
manager.

The change manager develops the business case for a major program of work. The executives responsible for the organization's portfolio management approve the business case and agree to fund and resource the program.

The program manager sets up the program management team, establishes the program
management office and charters a series of projects to develop the various deliverables needed to implement the change. And you have been appointed project manager for one of the projects.

In this situation, your life as a project manager would be fairly straightforward; you have direct-line management responsibility to the program manager, and the change manager is your project sponsor. The program management office looks after most of the issues of sourcing adequate funds and resources.

All you have to do is deliver the project's outputs as defined in the project charter.

However, part of your project ideally needs the cooperative input from a group of people
who will be significantly disadvantaged by the overall reorganization. This group is led by a 20-year veteran of the organization, whom we will call Mary. At the moment, Mary's loyalties are divided--at one level she wants what's best for the organization she has worked for all her life, but she also wants to preserve her team and keep the status quo.

Fortunately, you have enough domain knowledge in your team to bypass her input and produce the deliverables anyway. So what should you do?

Option one is to work to get Mary and her team's input--if not their positive cooperation--but risk delaying your project's completion and overspending the budget.

Option two is to use the knowledge you already have in the team to produce the deliverable and bypass the problem, thereby ensuring on-time and on-budget delivery. This option also minimizes the chance of Mary interfering in the overall work of the project and program.

What would be your recommendation to the program manager? Option one, two or something different? Post your thoughts in the "comments" section and we shall draw some conclusions in my next post.

I like coffee. The smell of the freshly brewed morning cup of coffee invigorates me. Just this morning I met with my mentor and I prepared as usual by getting to the cafeteria early with my cup of coffee in hand.

Our conversations usually range from project war stories to best practices and lessons learned. This time around, the discussion centered on a "must-win" proposal effort. You feel confident about the current proposal, but the day before the submission, you're called into the executive office and told the final cost must be reduced by another 20 percent.

Thoughts swirl through your head. Given that you're the project manager, you'll have to update the basis of the estimation so it supports this new, lower cost.

Many times a must-win proposal means being the lowest bidder, hoping to make up the difference from future change requests. If this is the case, then the direction from the executive office borders on unethical conduct.

Why? Because within defense contracting, a firm fixed price contract is the preferred choice for the government because any overrun would come out of the contractors' profit margin. Imagine that you know it would really take you US$100 to do the job but you bid US$80 knowing that you're the lowest bidder in order to win the contract in the first place. Once you are awarded the contract, you employ various strategies to bring to light that the customer really needs additional "enhancements" in order to fully execute their missions. Magically, the total cost of the enhancements seem to add up to another US$20, plus additional margin.

All bids must provide basis of estimation (BOE) to justify the dollar amount. On the day before the proposal submission if you are directed to lower the final bid number by 20 percent and there is no way you can revise the basis of estimation in time and you signature is on the proposal, then you are lying to get the business.

So what do you do? 

I think that if the original basis is sound and was validated through independent review, then it's the job of the project manager to say no and explain why that can't be done without compromising the integrity of the submission.

Before I could for a response, my mentor said it was okay not to have an answer right then. When that day comes, my action will be rooted in principle and on doing what's right.

Does the end justify the means?

On a personal note, I'll be taking December off in anticipation of a new addition to our family. Best wishes to you for the various holidays coming up.

Recently I had the opportunity to put together a "sales pitch" presentation to inform a potential customer about a latest and greatest widget. The audience included a vice president, a manager, some end users and a finance analyst. Since this presentation could potentially bring in a sizable amount of work for our team, I was nervous from the start.

Throughout the briefing, there were a healthy amount of discussions going back and forth between our team and our potential customer. Momentum was high after I concluded a few live demonstrations.

However, toward the end of the presentation, the infamous question came up, "How much is this going to cost?" My manager was the intended receiver of the question. There were some initial unintelligible hums followed by a long pause.

Then I interjected and started to describe a comparably scoped project that we'd done and how much resourcing it took to complete. I pointed out the similarities and proceeded to work with the audience in flushing out a detailed project scope. We concluded the briefing with a favorable impression and an agreement to continue our engagement.

As we traveled back to our office, I realized in answering for my manager that I'd decided to act on the notion that it's easier to ask forgiveness than to request permission. I am curious to know what my fellow project managers thing of this idea ...

In my case, my manger made a comment later that he would need to add "Pitch Man" to my current title. To my relief, he was smiling.  

Reporting project status can be exciting--or can be one of those things you'd do anything to avoid.

By conducting frequent, but relevant and appropriate status reviews, including the stakeholders in the process and presenting fact-based information, you will help to avoid any unpleasant project surprises.

To make the reporting process run smoother, project managers should consider these elements when preparing their reports:

Timeliness: This is all about the reporting cycle, the aspects of "when" and "how often" you report. Pick times that will most benefit the stakeholders.

Fact-Based Information: Validate information before it's reported to the stakeholders and produce trustworthy reports that others can base critical decisions on. These steps help gain stakeholder confidence and contributes to the overall success of the project.

Relevance: Know whom you are reporting to and what information is relevant to that stakeholder.

Appropriateness: Be aware of any sensitive information that should be presented only to specific individuals.

Presentation: Spend a little time identifying the medium - such as handouts, e-mail, verbal, telephone -- as well as the method -- free form, discussion-based or single-person, etc -- for the report.

Knowledge: When you don't have the full details on information to be presented, invite a direct resource that produced the result to the presentation.

Audience: Focusing on specific individuals or groups allows you to provide relevant and appropriate information.

By considering all of these elements, you can present a clear picture of the project's status to the necessary attendees.

Acknowledging people for the contribution they make to a project team or to their organization is such a simple matter. It's something I say repeatedly wherever I can get on my "soapbox": We can acknowledge people at any time, at no cost, without having to buy anything, install software or study an instruction manual.

Last night my soapbox was a live webinar attended primarily by project managers from all over the world, including Hong Kong, China, India, Brazil and the United States.

During the seminar I asked participants, "How do you feel when you complete a project that you put your whole heart, soul, body, mind and spirit into for the past several months, the users love the end result and your manager gives you nothing more than a quick 'thank you?"

This was the response via text chat:

Thomas: discouraged
Tanya: feel used
Srikrithiga: not interested to work
James: discouraged
Suganthi: Discouraged
James: feel indifferent
Sanjib: feeling of being empty--what was I doing all the time?
Ravindra: No motivation
Tanya: I won't give my best effort
Linda: lack of loyalty
Linda: feeling insecure, not as interested in working so hard
Fabricio: lack of motivation
Jade: feel not being valued, lack of respect

Then I asked, "How do you feel if your manager tells you what a difference your work made to the project team, how your contribution made the project a success, how much the users loved it, that she was getting wonderful feedback on it, and that the next time you would get more resources so you didn't have to work so many nights and weekends?"

And they answered:
 
James: I would feel appreciated; that motivates me
Shelley: Motivated...willing to give an even greater effort
Linda: enthusiastic
Ravindra: I would make extra efforts
Mariano: I would feel like a giant
Jade: more loyalty
Linda Benedict: my confidence would be boosted by the acknowledgement
Srikrithiga: I would give 200% for work

Performance, loyalty, engagement, confidence, motivation, self-worth are all functions of acknowledgment rather than compensation.

Especially during these challenging economic times--when everyone is working harder and having to do more--let's do our best to create a culture of appreciation in which people know their value and their worth.

There could be nothing simpler and more satisfying and with greater results.

In my last post I said "conflicting leadership initiatives" was one of the factors leading to current overhead reductions at my company. Let me explain. Conflicting initiatives arise from the fact that senior managers do not want to trade off anything from the cost-performance-schedule iron triangle (low resource commitment with high payoff expectation which is to be delivered right now).

A decade ago, senior management got excited about agile methodologies. Instead of rushing out to do a complete makeover and implementation, the company started with small but safe pilot programs, and the results were promising.

Based on these early successes, agile methodologies were then mandated to several large key programs. But this agile mandate failed to account for the scalability of the results and project size, and these large programs soon ran into issues. (Our large projects have geographically dispersed teams including various tiers of sub-contractors and suppliers and the initial pilot programs did not model this type of project profile.)

Significant problems began to affect the company bottom line. And as soon as that happened, program managers dropped the agile mandate like a sack of potatoes and focused on fixing issues and steering their programs back to some level of stability.

Now we are in the middle of CMMI level 3 certification. Much money had to be diverted into fixing many of the gaps caused by the decades-long agile experiment. For instance, our program portfolio consists of a mixture of traditional waterfall, agile and even ad hoc projects that would prevent our business unit from reaching level 3--and not reaching it that level is simply not an option.