Forward Momentum: Delivering Results

By Kathy Martucci, PMP

Strength, balance and flexibility….basic foundations of yoga AND good project management.

Try this: the next time you’re in a particularly galling meeting, inhale deeply through your nose all the way from your abdomen through your rib cage to your chest. Feel your breath bathing your inner body with light and tranquility. Hang onto that breath for a brief moment before you quietly expel it through your nose discharging all your tension and that overwhelming urge to slap whoever it is in your face now.  Soften your shoulder blades. Repeat until your blood pressure is in normal range. WOW.  That could have been the lead-in line to any yoga class.

I’ve been thinking a lot about the similarities between yoga and project management. It’s weird, I know, but kind of intriguing.

Practice strength

Most people think yoga is all about stretching. Yes, there’s a fair amount of that. But have you ever seen a yogini in crane pose, efficiently balancing her entire body weight on her palms?   It takes that kind of confident strength to be a good project manager…strength of character, integrity, perseverance…all major success factors for any PM.

Develop flexibility

Here is where the mainstream thinking of yoga lies and perhaps it’s those photographs of people in contortionist-like postures that fosters the myth. In project management, flexibility is the name of the game. Have you ever experienced an environment that requires contortionist moves and is more in need of flexibility than a project?  Creative thinking, problem solving, meeting challenges with an open mind and an ability to not just react but be proactive – all basic requirements to survive a project, let alone exceed expectations.

Cultivate balance

Stand in tree pose for 5 minutes. Sounds easy – try it sometime if you’d like a challenge.  Over time, you can improve balance with sustained practice.  In project management balance is key.  Shuffle resources, juggle priorities, maintain a work-life balance…easier said than done but critical to success.  Practice balance, improve balance.

Namaste.

by Craig Covello, PMP

You may be to young to remember a blues song entitled, “The Thrill Is Gone.” It was written in 1951 by Rick Darnell and Roy Hawkins, and later popularized by blues guitarist legend B.B. King in 1970. Allow me to share a sample lyric:

The thrill is gone
It’s gone away for good
Oh, the thrill is gone baby
Baby its gone away for good
Someday I know I’ll be over it all baby
Just like I know a man should

I’m sure that Mr. King was referring to intimate relationships; however, let’s examine this from the context of project management, because there are some legitimate parallels.

When someone in the company has an idea, they typically embark on a campaign to solicit executive sponsors by generating some enthusiasm. It’s almost an evangelical process. But as with many ideas based upon vision, excitement and desire, the view is typically somewhere between 50,000 and 60,000 feet.  Fortunately, or unfortunately depending upon your point of view, lack of detail is entirely compatible with the executive summary format used to pitch an idea to senior leadership. And once the project is given the green light, the very real process begins of putting together a plan to execute that vision into reality.

If you’ve been a project manager for any length of time, you know that the “project plan” is not synonymous with the project schedule. There are several other components to be developed, including identification of stakeholders and project participants along with roles and responsibilities. That’s where the concept of motivation may require little attention, because at the beginning of the project, most everyone is excited and engaged, or at the very least, somewhat responsive. But as the reality of project execution settles in, typically there may be signs of waning interest among some participants who have specific work to do, either through coordination of others or direct effort.

And that’s where the true, and sometimes underrated, value of the project manager’s role has tremendous impact. It’s no small feat to lead a group of individuals to the finish line, particularly when they have been temporarily assigned to you in a matrix organizational model, a model where participants know that you will not be writing performance reviews or deciding next year’s compensation. So perhaps it’s just human nature to sometimes ratchet down the level of attention and effort as the project progresses.

Here’s a case in point: Recently my wife and I moved to North Texas after 22 years of living in Northern California. We engaged the assistance of real estate agents on both ends of the transaction, selling our existing home as well as purchasing a new home. In both cases, it became obvious that the agents became noticeably less responsive once the offers were accepted for the California sale and the Texas purchase. Phone calls were not returned as promptly, details were forgotten and mistakes were made. In retrospect, the home buying experience was very anti-climatic and somewhat frustrating, all for lack of follow-through. In the real estate agent’s mind, it was all about closing the deal in order to receive the commission. In our minds, however, it was about a smooth transition from one state to another.

In the project manager’s mind, it should also be about a smooth and timely transition between project initiation, project execution and project closure. All details matter. All task due dates matter. That last mile in which many project deliverables are due may become one of the longest miles. Perhaps this is why so many projects, typically ones run by the government, are often embarrassingly late and significantly over budget.

How do you motivate project participants to stay engaged after the thrill is gone? That may be the subject for an upcoming article, because we don’t want the lyrics of BB King to become the prophecy of future projects.

Wouldn’t you agree?

by Bruce Beer, PMP

Note: This is part 3 of a 3-part series.

The first in this series of Keeping on Track blogs dealt with how to keep your project on track with regard to time, the second dealt with how to stay within budget, this final blog in the series now looks at keeping to defined scope and how to avoid the dreaded scope creep!

As with time and cost, to be able to meet your scope baseline you first have to establish it. Project implementation can either be based on a firm, solid bedrock of requirements or it can be built on the shifting sands of indecision, false assumptions and differing interpretations that will eventually sink the project and lead to project failure, recriminations, accusations, heated arguments and potentially a visit to the unemployment office for the PM. So what are the basic requirements for a solid scope baseline and how do we create one?

The first step, often omitted, is to identify ALL project stakeholders – anyone who impacts or is impacted by the project. “Why is this” I hear you ask. Well any one of those stakeholders may have a requirement that is vital to the success of the project, and if we miss this requirement it may take time, money, and added complexity to include it later. So we will interview, perform surveys, have workshops etc. to ensure we get the full set of requirements at this stage rather than during acceptance testing! However, note that not all stated requirements will be included in the final scope of the project because each requirement has to be cost justified.

Once we have identified all requirements we can then start building our project scope by first identifying the deliverables required to meet them, then discussing and agreeing these with the customer (the person paying for the project) to decide which requirements are “must haves,” “wouldn’t it be nice ifs,” and “bells & whistles.” At this stage, if there are any areas of uncertainty, they should be clearly identified as definitely either “In scope” or “out of scope” just so that there is no ambiguity or room for interpretation at a later date. Then we can create the Work Breakdown Structure (WBS) – the heart of all project planning – based on these deliverables, followed by a specification. The WBS together with the specification creates the scope baseline. The purists amongst you will know that there is a third element of the scope baseline, the WBS dictionary, but we will not consider this now.

OK so now we have a solid scope baseline. We know exactly what it is the project has to deliver and have created a detailed project plan based on the WBS. All we have to do now is to ensure the project meets the three baselines. Controlling and meeting the scope baseline is probably the easiest of the three baselines to achieve as there is one main process used to control scope – change management. This means that ANY deviation from the original specification will need to be formally requested, evaluated and authorized by the customer before it is implemented. Some people may think that any change that does not involve additional time or cost does not need to go through the formal rigor of change management. These are probably the people out on the street looking for a new job wondering why their life took such a sudden and unexpected downturn.

Let us consider an example where a customer wants to change the length of an address line from 25 to 30 characters. Let us assume this is recognized before the programmer has written that section of code, so there will be no additional time or cost just to extend that field. So why bother to create a formal change request for such a simple change? OK, well let us look at this from three main viewpoints: ripple effects, acceptance and stakeholder satisfaction.

1.       Ripple effect

If there is no formal change management process, the programmer extends the address line and keeps this as a well hidden secret because they do not want the PM to find out they did it. What harm can it do? Let us suppose the address is part of the order input screen. Other areas of the software such as invoicing will be working on the specified basis of 25 characters per line, so all printouts, disc records, searches, etc. would use this basis. So the ripple effects of this apparently innocuous change can be many and serious.

2.       Acceptance

Now let’s look at acceptance for the above. During acceptance testing, the person performing the test will look at the specification (25 characters), incorporate any formal authorized changes (none), and will expect the test to meet this combined requirement (25 characters). The tester puts in a 24 character address, expecting it to be processed correctly. Then they will try a 25 character line with the same expectation. Then they try a 26 character line and expect it to fail and produce an error message, and guess what, it doesn’t do this, it accepts the over-length line without any problem. The tester will then declare that acceptance test has failed.

Now let us consider the correct procedure. The customer creates a change request for the address field to be changed to 30 characters and gives it to the PM (all change requests must go to the PM). The PM logs it and sends it out for impact analysis. The analysis comes back identifying other parts of the project that might be affected by the additional characters and additional changes that might be required. Then it might say that there is minimal or no time or cost impact. The customer would formally authorize this change and the change is implemented. The acceptance tester will see the initial requirement of 25 characters, will have the authorized change to 30 characters and will test accordingly, and lo and behold it passes acceptance.   

3.       Customer satisfaction

Now let us look at customer satisfaction. Consider a fairly substantial change. If the change does not go through the formal process it will not be formally approved, so in addition to failing acceptance we now have additional time and cost to worry about. We as PM are measured against how well we perform against the project baselines (customer expectations) for scope, time and cost, so immediately the PM now fails on all three baselines. If there had been a formal approved change request, the project would then meet the scope requirement (initial specification plus formally approved changes). If the project took longer than initially planned but there are formally approved change requests providing an audit trail for the additional time to perform changes, then the initial time estimate plus authorized additional time is the new measure against which the PM will be judged. The same with cost – the initial cost plus approved changes is the new measure for the PM, so providing they meet their initial estimates plus allowances for formal changes, all is good and a pay rise is on the horizon. In conclusion, formal change management creates an audit trail of authorization for any change to the original baselines.

Most companies these days will have a formal change management process with which the PM should be familiar and use. One of the key areas discussed by a PM during the project kick-off meeting will be to review, explain and distribute copies of the change management process to all stakeholders. The PM should explain the serious repercussions of not following this process! If the customer is not at the kick-off meeting, the PM should review and agree the process with them prior to the start of implementation to ensure it is understood and agreed.

Final thought: if you have read all these blogs you will know they are highly interrelated. If time or cost start going out of control, one option depending on constraint priorities is to de-scope the project to bring it back on track. De-scoping will involve looking at “bells & whistles” first to see which can be removed with least impact on the end product. Once all of these have gone, the next object of your gaze will be the “wouldn’t it be nice ifs.” If you reach the end of these and are left with the prospect of de-scoping some of the “must haves,” you have a serious problem. Removing any “must haves” will affect the viability of the project, so at this stage scope cannot be reduced further. You will need to review cost and time to reach the optimum results.

By Vicki Wrona, PMP

A frequent concern and popular topic in our communications, leadership or project management training classes is how to deliver bad news. We commonly discuss techniques of feeling empathy, putting yourself in their shoes, sticking to the facts, avoiding under-reacting or over-reacting, etc. Recently, I came across an Insight Roundtable discussion in Whole Living magazine (May 2011, pp.126-127) that discusses this topic nicely.

The question, “How do I deliver bad news?” was answered by a doctor, a communication expert and a consultant.

1.       Doctor’s response

Neha Sangwan, M.D., CEO and founder of Intuitive Intelligence, Inc.

Do not surprise people. Let them know what you would like to discuss, how long it will take and ask them for a good time to meet. That way, they can prepare for the conversation and have some control over it.

During the conversation, be honest with them. By letting them know that you are nervous, surprised, etc., you let them know of your positive intention and that this conversation is difficult for you, too. Present the information as clearly and compassionately as you can, keeping in mind that this person is strong enough to handle the news as best they can. If the other person reacts emotionally, reflect back what you observe. (“I understand this is upsetting to you. How can I help?”)

After delivering the news, stop and allow the other person to absorb your message and respond. Don’t fall into the usual trap of continuing to talk.

2.       Communication expert’s response

Debra Fine, speaker and author of the Fine Art of the Big Talk

Start your message with something positive. For example, if you can’t afford to attend a friend’s wedding on a tropical island, let them know how much you value their friendship, how important this special day is, and that you are disappointed to let them know you will not be able to attend. At this point, don’t offer details or excuses. Own your decision by stating your decision in “I” terms (“I cannot attend”) versus “you” terms (“you picked an expensive location”).

Deliver this message in person if at all possible, and over the phone if not. Do not send this over e-mail. When talking to them, maintain eye contact.

3.       Consultant’s response

Donna Flagg, author of Surviving Dreaded Conversations

Understand that this is a conversation, not a conflict. Be clear and honest. Do not play the victim yourself. Stick to the facts of the situation without blaming management or adding to the story. Blaming and enhancing can and will make you look defensive or insecure.

Even though you are speaking to the facts, do so with empathy and kindness. By staying focused on the facts and accepting the reality of the situation, you help the other person move forward by doing the same. Imagine how this could work while talking to someone about a reduction in force (RIF) and that you have to lay them off, for example.

Rehearse your talk ahead of time to ensure it goes as well as possible. Practice this over time and it will become easier to deliver bad news.