Recently in Leadership Category

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.

Portfolio direction is how an organization decides to invest its resources in different types of activities. Portfolio direction sits above the project portfolio--covering all the organization's activities.

The first step in portfolio direction is to identify the organization's main activities.

Here are the three main types:
•    Change actions (for example strategic programs, change projects)
•    Incremental actions (for example improvement projects, systems updating, continuous improvement)
•    Ongoing actions (for example administration, operations and maintenance)

Many organizations also consider mandatory actions (such as conformity projects or regulatory requirements) as a distinct type of activity. However the organization divides its activities, it is important that there be no overlap between activities and that every area is covered.

The decision to invest in a portfolio direction is highly dependent on the organization's corporate strategy. For example, if the organization is in a turbulent environment and needs to be highly responsive, it will invest more in change activities. If, on the opposite end of the spectrum, it is in a stable environment and occupies a good market position, it will invest more in ongoing activities. If the investment strategy is not clear from the start, the organization will invest its resources in activities that will not support its strategy.

Once the organization has decided which percentage of its resources it should invest in changes--incremental and ongoing--it must develop selection criteria that these actions should fulfill. For example, criteria might indicate that change actions must support market penetration, a strategic initiative or help resolve a significant issue.

In general, every investment decision of the portfolio direction should ultimately increase the organization's responsiveness and competitiveness.

How do you make good decisions? While we don't usually ask ourselves this question in our day-to-day activities, it becomes critical when we are faced with tough situations as project managers.

Several factors contribute to making good project decisions:

Experience: Experience is usually associated with time spend within the industry/domain. But while a project manager gains invaluable wisdom over time, I am a firm believer that training with hands on simulations and role-play scenarios can fast track our ability to effectively tackle challenging situations.

Process: Process refers to the training--on the job and/or formal methods--that a project manager has internalized according to their personal strengths. When I approach or encounter difficult decisions, I typically:
•    Identify the root problem by asking why multiple times
•    Prioritize options with pros and cons
•    Seek to learn from my decisions

Guiding principle(s): Guiding principle is the wisdom that project managers gain from understanding past mistakes. The principle that guides me as a project management professional is the 80/20 rule (Pareto's Law). The 80/20 rule is often observed in real life (or systems) to show that approximately 80% of the work seems to come from 20% of the sources.

When I am faced with 100 items on my to do list, I have a couple of options to tackle the workload:

•    Spread my effort evenly across all 100 items and hope for the best (meet project deadline that is)
•    Utilize the 80/20 rule--Prioritize and work on 20% tasks that when completed would bring the most value to my project.
 
In other fields such as software development, Pareto's Law is often applied to the case that 80% of the defects seem to originate from 20% of the software modules. 
 
Keep in mind that this is approximation, yet a lot of empirical data seems to point to a variation between 10% to 30%, but the name 80/20 stuck as what we the project professionals refer to in today's world.

Courage: While everyone may know the right thing, it takes courage to actually follow through in the face of adversity.

For more on using "why" as a way to define a problem, see this Tip for Team Members from PMI Community Post.

I am writing after having just finished conducting a seminar in Bahrain and am preparing to fly back to London tomorrow morning.

For the third year in a row, CIOs identified project alignment with the strategy as the number one management priority in a CIO magazine survey. And for the first time, CEOs rated "meeting other strategic objectives (e.g., reputation of your business, entering a new market, securing access to natural resources)" as more important than "maximizing financial or shareholder return" or "meeting or exceeding a specific financial return" (e.g., return on invested capital).

In most organizations, business heads select the majority of projects. Those projects are then submitted as part of an annual budget allocation process, with the selection often based on these functional managers' needs, not as a response to an aligned strategy.

Often these initial proposals have to be cut back when budgets are reduced. And because the current organizational focus is on short-term results, the projects that are cut are mostly those that would produce long-term results. But the recent economic downturn has brought into light the failure of the short-term financial profit approach and the need to look for longer-term sustainable value. Recent surveys show the interests of top management are shifting; increasing competitive advantage and the ability to adapt to change have become foremost in their priorities.

The key to delivering this value is in the development of an integrated portfolio-program-project approach supported by a sound governance system. Typically, executive stakeholders agree on the strategic objectives that will produce competitive advantage. At the program level, they are translated into business benefits. Project deliverables are then defined to produce new capabilities that will enable the realization of these benefits.

As project results are measured and benefits are assessed, the program and the strategy are modified to adapt to changing circumstances. This, in turn, gives the organization the necessary agility to stay competitive in a challenging environment and to realize value consistently.

Picture yourself coming to work one morning only to find a scathing e-mail from a client, supervisor or stakeholder, detailing in painful, angry detail how you messed up. What do you do?
    First, keep calm. Then, consider these points:

1. Control your emotions: Chances are that emotion is at an all-time high so your natural instinct is fight or flight. But that will only make things worse. Fighting would be like adding fuel to a burning fire. Withdrawing would make the other party more frustrated at the situation--forcing them to act on emotion rather than logic. Instead, apologize as your opening response; this is a tool for diffusing the emotion and for keeping all parties sane.
2. Establish rapport: Clarify what misconception or misunderstanding your customer may have about your role as anything other than an advocate for them.
3. Express understanding: While it may be impossible to predict the future, provide a plan on what you will do to help mitigate surprises. Even though this time your only option may be to offer an apology, it still signals that someone cares.  
4. Ensure success: Promise what you will do and do what you promise. Nothing reassures your customer more than seeing for herself that you follow through on your plan--even if this means lots of caffeine, late nights and weekends.  
   
    Good luck!

Are you failing to rake in the respect, admiration and monetary recompense that are consistent with your advanced level of project management expertise? If so, you need your own business or management model, complete with its own slick-sounding acronym, in order to truly set you apart and make you stand out in a crowd of (otherwise) management equals.
    This is easier than it looks. For example, someone can, say, set up a traditional Responsibility/Accountability Matrix (RAM), deconstruct them into detailed instructions with lot's of fuzzy terms like "strategic," "engage" and "implement", slap an acronym on it--like RACI (Responsible, Accountable, Consulted, Informed)--and voila! They've developed their very own management model.
    I love reading the synopses in the management course catalogues I get in the mail (yeah, I know, I need to get out more). You can almost track the entire debate among the Agile management practitioners, the Scrum advocates and the more traditional Waterfall Model believers just by reading what the instructors or paper presenters believe they are bringing to the table.
    I know: I'm inviting a truckload of comments questioning my intelligence. But Agile management strikes me as little more than the practice of loosening up baseline change control parameters to the point of almost begging scope creep to hit your software project in a bid to acquire the kind of managerial latitude needed to deliver software faster. Throw in some trendy tactics, like re-arranging the desks in the office and bring along the ever-present admonition to achieve better communications (especially with stakeholders), and then you can profoundly influence the conversation on management theory around the globe.
    I first became aware of the practice of deconstructing already-existing management practices and trotting them back onstage re-packaged during the 1980s, when "Activity Based Costing" was suddenly a hot topic. For you gen-exers out there, Activity-Based Costing (note how easily the acronym falls off the tongue: ABC) was the idea that a project's basis of estimate should be created at the lowest level of the Work Breakdown Structure, or activity level, and "rolled up" to total project cost. Problem was, this was the way that valid estimates had been created since the dawn of project management. Besides, what's the alternative? Estimating based on the availability of the organization's resources? For manufacturing, process or asset management, that might be a workable approach, but it was never so in the realm of project manager. Nevertheless, a plethora of ABC-themed paper presentations' titles started appearing in project management and cost engineering seminars. True to form, of the ones I attended, the content was made up of deconstructing the act of generating the basis of estimate into some sort of process guide--almost like a recipe--and then sprinkling in vague but trendy management-speak terms to make it appear new, or more sophisticated.
    To engage in a bit of deconstruction myself, at the end of the day all management models are nothing more than formulaic attempts at telling other people how they should be managing their projects. I can see why such models are appealing to consultants. But, for the rest of us, do they really merit all of the books, articles and presentations devoted to them?