Tag: Stakeholder

From the Sponsor’s Desk – Tenacity Can Achieve Miracles

Written by Drew Davison on February 22, 2012. Posted in Articles. 16 Comments on From the Sponsor’s Desk – Tenacity Can Achieve Miracles

Tenacity_Fotolia_12319244_XS In my last post, Knowing Your Project Profiles, we looked at the approach one CIO took to confirm his gut feeling that a project was going to be well over budget and behind schedule.

In this post, we’ll see the results that were achieved through the tenacity and commitment of one Quality Assurance manager to turn around a company’s sagging fortunes and renew client confidence in their products and services. Thanks to reader M.D. for the details on this case.

The Situation

This provider of billing and customer information services to the utilities industry was experiencing significant customer dissatisfaction with the quality of its applications and services, contributing to loss of customers and a serious revenue decline.

Software updates and releases were handled by the internal development group. Responsibility for quality was shared between the programmers on each project and a central quality control unit. There were no standard development or quality practices. The development teams relied upon previous approaches used on a specific software package or service. The sales organization, which drove much of the enhancement activity, placed much greater emphasis on time to market, which was a significant contributor to the quality problems.

The CEO challenged the CIO to turn the situation around quickly through an order of magnitude improvement in the quality of delivered software and services.

The Goal

The CIO recognized that a number of changes would need to be made to their practices to achieve the CEO’s mandate.

He proceeded to hire a manager to head the quality assurance function and guide the other changes. She had a wide range of experiences and accountabilities and an impressive track record. Her mandate was to deliver the changes within an 18 month time frame and achieve the targeted order of magnitude quality improvements to increase customer satisfaction and reverse the revenue decline.

The new QA manager took over a team of 32 staff, half of them located centrally in head office, the rest in four other offices spread across the country plus a small offshore testing facility in India. She was also responsible for supporting 60 applications and services for over 50 clients, most being large, very demanding utilities.

Her first week on the job was spent talking to the senior managers and staff to get their thoughts on what problems existed and how best to tackle them. She discovered the following views:

There was inadequate documentation on the core systems and services, inadequate documentation about business requirements and application functionality for new offerings and a mishmash of project management practices to guide the projects.
There were frequent and ad hoc changes to the planned new releases.
There was an absence of standard project management, development and quality practices which hampered the movement of staff to priority projects and created conflict and ill will when dealing with other organizations and clients.
There were no controlled test environments for the core applications and services and no management and reuse of test conditions, cases and scripts.
There were ongoing communication gaps among the development groups, Quality Control, Computer Operations, Sales and the clients.
There was no or limited technology available to support requirements traceability, test planning and execution, release builds and promotion to production

She did a stakeholder map to identify who her key partners in this endeavor would be. They included:

The CIO, who identified himself as sponsor of the change.
The VP Sales, a key target because of the relationship with the sales staff and their clients.
The VP System Development, also a key target because of the planned changes to development and quality practices
The VP Computer Operations, an important target because of the planned changes to improve the build and promotion processes and the need for more responsive client support.
The clients, for obvious reasons.
Herself, manager of QA, as the change agent and also an important target because of the changes she would have to implement in her own organization

With the exception of the client representation, this became her initial stakeholder group. The Sales VP would wear two hats, as a proxy for the clients and representing the Sales organization. All material decision would be reviewed and approved by these players. All decisions needed unanimous consent.

Her next step was to develop and vet the vision for the changes that were needed, including the sequence of implementation and the planned time frame. When she had obtained senior management buy in, she launched her project. Her budget was just over $800,000 including software.

The Project

The first order of business was to communicate the vision to all those who would be affected by the upcoming changes. The Sales VP and Operations VP cooperated fully and encouraged their managers and staff to listen, provide feedback and get on board. Her vision called for a first wave of process improvements including the project management, development and QA processes, a testing technology project and a metrics and reporting initiative. These were to be followed by a second wave including release coordination, configuration management and document management

The Development VP refused to return her calls and didn’t attend her meetings. She went below him to a Development manager who had taken considerable heat for quality issues on his applications and had expressed a desire to be an early adopter of the new practices.

She formed a team with representatives from the Development manager’s group, Operations, Sales and QA to evolve the project management, QA and development processes. The mandate to that team was to use the best in house methods available and beef them up with industry best practices, from PMI, SEI and QAI among others, in a six week time box. That work was completed in the targeted six weeks and included high level documentation, references to external best practices, examples where possible and general training materials.

She appointed an experienced QA lead to manage the implementation, starting with the supportive Development manager’s team and two projects just getting underway. As those two projects progressed in applying the new methodologies, gaps were identified and plugged, errors and omissions were fixed, new examples were collected and training materials and methods were updated.

On the testing technology side, the QA manager had been through a formal technology assessment, selection and implementation process in her last job. She was very familiar with the available offerings. In the interests of time, based on that experience, she pulled together a formal recommendation including assessment of the available alternatives and specific recommendations and reviewed it with the stakeholder group. All except the Development VP approved the proposal. In spite of the requirement to have unanimous agreement on all stakeholder group decisions, the CIO (the sponsor of the initiatives) gave approval for the QA manager to proceed with the technology acquisition and implementation and indicated he would work with the Development VP to resolve his concerns.

The QA manager proceeded to form another team, led by another of her QA leads, to implement the technology and develop standards and practices and then apply those to supporting the two development projects. The team included staff from Operations, QA and Development (from the supportive Development manager’s group). She was also able to get a staff member from the client involved with the two development projects.

On the metrics front, she consulted with the CIO and VP Sales about their views on the metrics required and, based on those discussions, recommended three initial measures: customer satisfaction and the change from period to period; quality, as measured by the number of critical system defects (failures in production) and IT productivity, as measured by revenue per staff. The last metric, site productivity, was an attempt to measure revenue growth in conjunction with improvements in IT productivity. With the exception of the Development VP, the stakeholder group approved the recommendations. The QA manager was given the green light to proceed.

After two months on the job, the QA manager had built and sold a vision and developed, pitched, received approval for and launched three key initiatives. She communicated formally on a weekly basis up, out, down and sideways. She also engaged anyone who wanted to talk about the program in the form and timeframe appropriate to the need. And, she took it upon herself to monitor the grape vine, to see what people were thinking, feeling and saying.

While all this was going on she also executed her duties as manager of the QA unit and helped her staff not formally involved in the three projects get up to date and on side.

The Results

The three initiatives were extremely successful. On the process initiative, the first two projects were delivered with zero critical defects and slightly beyond the initial target dates. However, the client was thrilled, to some extent due to the involvement of their staff in the testing technology undertaking. The testing technology project worked with the two project teams and the process group to build and reuse test scripts to cover the changes being made, resulting in much better test coverage, less time to execute, improved productivity and better quality. On the metrics front, the tie-in of the three metrics to IT staff bonus calculations and publishing the monthly results throughout the company had a palpable effect on the company culture. The CEO noted the effect in one of his quarterly updates.

The first wave of changes was rolled out across the organization in fourteen months. The second wave was completed in an additional ten months. Here’s how the actual results looked:

Metrics	Before Changes	After One Year	After Two Years
Customer Satisfaction (1-Very Dissatisfied 10-Very Satisfied)	4.1	6.3	8.4
Critical System Defects	41	3	0
IT Productivity (Revenue/FTE)	$48K	$55K	$81K

One final note: the Development VP, who opposed the QA manager’s plans and refused to participate, was replaced.

How a Great Change Agent Helped

This is an interesting study. Obviously, all the initiatives clearly qualify as projects. Yet the QA manager didn’t really run them according to the usual model, with clear requirements, sign-offs, prescribed phases, etc. There was no risk plan, no issue log, no formal change control, no test plan, no detail project plans.

What allowed the QA manager to achieve these stellar results? I think five factors contributed to her success:

The QA manager had the knowledge, skills and capabilities to lead the initiative. She understood enough about project management and software development to understand the relationship to quality and productivity. She had a deep understanding of quality assurance, quality control and supporting technologies. She had the knowledge on tap to create the vision and the plan and get it approved.
She knew, either instinctively or formally, how to manage change. She pulled the stakeholder group together. Instead of waiting for the Development VP to get on side or get lost, she went below him to a supportive and needy Development manager. She knew she could get away with the move because she had the support of the other stakeholders. She leveraged the burning platform – declining revenue and customer satisfaction – to get the decisions and resources she needed.
She was a confident and gifted communicator. She communicated frequently, to all affected targets. She listened and acted on the messages she received. She involved the client, including bringing one client into the stakeholder group in the second year.
She knew how to form effective teams – small groups of staff with clear mandates, appropriate availability, the right perspectives, knowledge and skills and short term time frames to deliver an actual result.
She acted! She didn’t wait around for someone else to tell her what to do. She didn’t wallow in analysis paralysis. She went out and got stakeholder approval. She took clear, decisive steps. She did what she said she was going to do. When things went wrong, and they did, she was the first to acknowledge a problem and collaborate with those affected to seek an acceptable resolution.

Perhaps this is an example of how to use some Agile principles to deliver better, faster business solutions.

If you find yourself in a similar situation, remember to consider Project Pre-Check’s three building blocks right up front and put these points on your checklist of things to do so you too can be a Great Change Agent, and your sponsor’s best friend.

In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll have a go.

Don’t forget to add your comments below.

Tangoing Your Way Through the Executive/PMO Relationship

Written by Curt Finch on February 6, 2012. Posted in Articles. 16 Comments on Tangoing Your Way Through the Executive/PMO Relationship

“It takes two to tango.” This idiomatic expression, which originated in a 1952 song by Pearl Bailey and was later popularized in 1982 when President Ronald Reagan quipped about Russian-American relations, is an accurate description of the relationship between a project management office (PMO) and an executive. At the end of the day, success for either of them is dependent on the other. Executives depend on the work accomplished by project management offices for their own success, just as project management offices depend on executives for their success.
In a provocative 1999 article in Fortune magazine that addresses why executives fail, the authors get directly to the point and state that the number one reason for executive failure is “bad execution…as simple as that…not getting things done…not delivering on commitments.” The article also states that executives who do not deliver are three times more likely to get fired than their counterparts who are delivering. Think about it. What is the dominant purpose of a project? Getting things done! Projects deliver products and services, and they do so according to a schedule. Projects deliver on commitments. Executives need projects so they can deliver on commitments, thus avoiding the number one reason for executive failure.

The opposite is equally true. Projects need executives. The scope of projects and the judgments made about their success have expanded over recent years to the point where project success is almost always beyond the sole control of those running the project. Project success is highly dependent on the availability of resources typically not under the direct control of the project manager. Similarly, the project manager does not have direct control over the networks and systems that their project must fit into. Really, the project manager doesn’t have direct control over much of anything upon which the project’s success depends. The days of the small, relatively simple, stand-alone project are mostly over. These dependencies, which are essential for the success of the project, are less often in the domain of the project manager and more often in the domain of the executive. The project manager must establish a PMO that is run with a direct two-way supportive relationship with the executive.

A Real Story
To illustrate just how pronounced the dependence between executives and project management offices is, and needs to be, let’s consider the following story. This story illustrates just how effective a strong co-dependent relationship can be. Prior to the creation of the PMO with a co-dependent executive relationship, trouble was the norm. After the creation of the PMO with a co-dependent relationship, the situation improved. The story is associated with responsibilities that the co-author of this article, Michael O’Brochta, had when he worked as an employee of the Central Intelligence Agency (CIA). He spent decades there managing hundreds of projects, managing project managers, and leading efforts to advance project management within the organization. The story begins with a strategic need within the organization and an executive who recognized this need and made a commitment to take action. Note that this is not a unique story. In a 2009 book by Brian Hobbs, PhD, PMP, titled “The Project Management Office (PMO): A Quest for Understanding,” he highlights a global study of project management offices and describes the PMO best practice of tailoring the PMO function to match the needs of the executive, just as happens in this CIA story.

“I don’t understand it; I have staffed my new organization with hundreds of highly-skilled project managers, yet even after our first year in business, we can’t seem to deliver enough projects on time or to the satisfaction of our customers.”

These were the words that O’Brochta first heard when the director of the organization asked for help. He went on to describe the gap between his vision for his organization and the current reality: “I’m confident that running this organization as project-based is the way to go, but I never thought it would be this hard,” said the director. “I periodically review project schedules, and find them to be ever changing. No one is happy about a moving target — not me, and least of all, not the customer. Quite frankly, I do not see why anyone would come to my organization if they had a decent alternative.”

The project-based organization described here was formed to advance the mission of the CIA. The best engineers, the best information technology professionals, and the best project managers were combined into a single organization focused on delivering new and better intelligence analysis systems and capabilities. One of those systems, named Fluent, was described a decade ago in a Reuters article titled “CIA Using Data Mining Technology to Find Nuggets.” This was cutting-edge technology focused on critical CIA mission needs at the time.

Finally, the director got to the point of the conversation: “Will you come and help?”

During the following year, O’Brochta built and ran a strategic-level Project Management Office. Although the published knowledge associated with successful project management offices was rather limited at the time, enough was known for him to select a couple of starting points. O’Brochta started with one initiative focused on the project managers and one initiative focused on the executives. For the project managers, he led the building of a standardized project life-cycle methodology complete with milestones and documentation tailored specifically for the nature of their work. For the executives, he led the building of a standardized governance system complete with reviews, decision-making criteria, and change management strategies tailored specifically for their work.

Previously, the role and actions of the executives and the project managers were out of sync. Project managers were doing their best to draw upon their extensive backgrounds to create and follow project plans, but no two were the same. Likewise, executives were doing their best to support the project managers with resources and decisions, but inconsistency and unpredictability were common.

O’Brochta routinely met with executives and others in the management chain to ensure that decisions about the PMO’s focus matched its needs; he did the same with project managers and the various PMOs. Both the executives and project managers learned that each group performed equally important, but different, roles. The executive’s role included supplying a standardized project life-cycle methodology for the project managers to use and holding them accountable for using it. The project managers’ role included tailoring the provided life cycle methodology and putting it into practice. The executives established and followed a routine for project reviews and associated decisions. The project managers prepared for each of the project reviews with the information needed to support the scheduled decision-making. Predictability and consistency became the norm. Effort that had been directed toward “figuring out what to do” was now directed toward more productive activities associated with running the projects and meeting mission needs.

Initial Reaction
Because of the success of the initatives, the value of the project management office was established. Other initiatives followed, all targeted at the co-dependent relationship between the executives and the project management offices. These initiatives included training for both the project managers and the executives. They reflected the maturing of project management within the organization and the value of strengthening the co-dependent relationship between executives and project management offices. It was learned that this relationship is, in and of itself, a project that can be planned and managed within a PMO for the strategic long-term benefit of the organization.

What’s Next?
As satisfying as it might be to establish a successful PMO, the question arises about how to keep them going. This is a serious question. It appears that keeping a PMO going is not so common. A 2007 PMI-sponsored report titled “The Multi-Project PMO: A Global Analysis of the Current State of Practice” states that PMOs are frequently closed or restructured with only about half of them surviving for two years. That’s a grim statistic. Executives need projects, project management, and PMOs. Yet, the PMO often struggles to survive. Why? According to the same study, the successful PMOs were the ones that responded to and adapted to the ever-changing needs of the organization. In other words, the successful PMO’s performance was matched to the needs of the organization. Key performance indicators were established and achieved. And not just any key performance indicators were achieved, but ones that were relevant and meaningful to the executives with whom the PMO had a co-dependent relationship.

Coming up in Part 2: Specific key performance indicators that a newly-established PMO can use to measure itself to ensure alignment with the needs of the organization.

Don’t forget to leave your comments below.

Michael O’Brochta,PMP, has been a project manager for over thirty years. He is an experienced line manager, author, lecturer, trainer, and consultant. He holds a master’s degree in project management, a bachelor’s degree in electrical engineering, and is certified as a PMP®. As Zozer Inc. President, he is helping organizations raise their level of project management performance. As senior project manager in the CIA, he lead the maturing of the project management practices agency-wide. Since his recent climb of another of the world’s seven summits, he has been exploring the relationship between project management and mountain climbing. Mr. O’Brochta’s papers and presentations at PMI national, international, and regional conferences have consistently been popular and well received; his last three PMI Global Congress presentations have drawn the largest audiences at those events.

Curt Finch is the CEO of Journyx. Founded in 1996, Journyx automates payroll, billing and cost accounting while easing management of employee time and expenses, and provides confidence that all resources are utilized correctly and completely. Curt earned a Bachelor of Science degree in Computer Science from Virginia Tech. As a software programmer fixing bugs for IBM in the early ‘90’s, Curt found that tracking the time it took to fix each bug revealed the per-bug profitability. Curt knew that this concept of using time-tracking data to determine project profitability was a winning idea and something that companies were not doing – yet… Curt created the world’s first web-based timesheet application and the foundation for the current Journyx product offerings in 1997.

How Do We Market & Promote a Project to Ensure Success?

Written by Lisa Anderson on February 1, 2012. Posted in Articles. 7 Comments on How Do We Market & Promote a Project to Ensure Success?

As important as project teams, project tasks, and critical milestones are to project success, they do not compare to the importance of marketing. To succeed in today’s new normal business environment where sales are lackluster, cash is tight, resources are scarce and customer service expectations are high, project execution is no longer enough; instead, you must also be an expert at marketing your project to ensure it gains the right amount of attention and traction to accelerate project results!
The challenge is that project managers aren’t typically skilled marketers. We can block and tackle with the best of project leaders; however, when it comes to marketing and promotion, we pale in comparison. In my 20+ years of experience in working with project teams across a multitude of industries, geographies and project scopes, I’ve found a few simple marketing tactics to make a significant difference: 1) Communicate the value. 2) Use multi-media. 3) Word of mouth.

1. Communicate the value: Undoubtedly, the #1 key to success in marketing your project is to communicate the project’s value. How does it provide value to the company? Does it tie in with the company strategy? Will it free up cash flow? Improve service levels? Increase profitability? Have you updated your project team? Your boss? Your mentor? Any leaders who might be impacted by the project? I’ve found that there is no quicker way to ensure the speed of progress than to continually communicate the value to each person affected or impacted along the critical path – and preferably each person’s manager as well.

For example, in an ERP implementation, we had to rally the troops around the implementation of a piece of functionality. This critical path step would affect the shipping and receiving function in a way that would increase the workload temporarily. The only way we gained enough commitment to increase workload with an already short-staffed and overworked team was by not only communicating the project’s long term value to the logistics team members (and their contribution to it) but also by communicating the team’s impact to the project success to the manager responsible for the increased workload. The key was that the critical milestone was no longer a project team success; it was a combined logistics and project team success.

2. Use multi-media: Communicating the value once is not enough. However, even communicating it 10 times isn’t enough. In order to break through the barriers so that all related parties and company leaders understand the value of the project (and would be willing to support the project even when it becomes inconvenient), it is vital to communicate via multi-media. It’s much easier to ignore a simple conversation than it is to ignore multi-media.

There are countless ways to promote your project leveraging multi-media. First, utilize the company’s newsletter and promote your project – why will it add value, who is on the team, what accomplishments have been achieved, etc. If you do not have a newsletter, create one. I’ve yet to see a tasteful newsletter turned down by business leaders as it helps to rally the teams. And who wouldn’t like to read about their achievements in the news? Next, leverage the intranet. Create a section for the project. Utilize social media. How about a brown bag lunch session to talk about the project and ask for input?

3. Word of mouth: I’ve found that there is nothing more powerful than the word of mouth. Simple yet extremely effective. Create a buzz about your project. Soon you’ll have folks asking how they can help the team!

How do we create a word of mouth? Start talking about the project. Ask the project team to talk about the project. If each person finds 1 or 2 target people to communicate with about the project and its value, it will spread quickly. Make sure to include at least a few executives and leaders. Ask each of these folks if they would share a highlight with their team or someone with a related interest in the project or its results. Ask them for feedback. There is nothing more powerful than referrals. Soon, your project will be in the limelight. Remember, make it interesting, show enthusiasm and appreciate their ideas and feedback. The rest will follow.

The power of marketing is immense. Do you think it will be easier and quicker to ensure project success if just the project team is committed or if you’ve involved and engaged not only the project team but their key influencers and colleagues?

Don’t forget to leave your comments below.

Project Management Best Practices: Laying the Foundation

Written by Karl Wiegers on February 1, 2012. Posted in Articles. 8 Comments on Project Management Best Practices: Laying the Foundation

Bricklayer_33147456_XS Managing software projects is difficult under the best circumstances. The project manager must balance competing stakeholder interests against the constraints of limited resources and time, ever-changing technologies, and challenging demands from high-pressure people. Project management is a juggling act, with too many balls in the air at once.

Unfortunately, many new project managers receive little training in how to do the job. Anyone can learn to draw a Gantt chart, but effective project managers also rely on the savvy that comes from experience. Learning survival tips from people who’ve already done their tours of duty in the project management trenches can save you from learning such lessons the hard way.

This four-part series introduces twenty-one valuable practices that can help both rookie and veteran project managers do a better job. Perhaps these articles, which are adapted from my book Practical Project Initiation: A Handbook with Tools (Microsoft Press, 2007), can help you avoid some project pain.

The practices are organized into five categories:

Laying the foundation
Planning the project
Estimating the work
Tracking your progress
Learning for the future

When initiating a new project, study this list of practices to see which ones would be valuable contributors to that project. Build the corresponding activities into your thinking and plans. Recognize, though, none of these practices will be silver bullets for your project management problems. Also, remember that even “best” practices are situational. They need to be selectively and thoughtfully applied only where they will add value to the project.

Practice #1: Define project success criteria.
At the beginning of the project, make sure the stakeholders share a common understanding of how they will determine whether this project is successful. Too often, meeting a predetermined schedule is the only apparent success factor, but there are certainly others. Begin by identifying your stakeholders and their interests and expectations. Next, define some clear and measurable business goals.

Some examples are:

Increasing market share by a certain amount by a particular date.
Reaching a specified sales volume or revenue.
Achieving certain customer satisfaction measures.
Saving money by retiring a high-maintenance legacy system.
Achieving a particular transaction processing volume and correctness.

These business goals should imply specific project success criteria, which again should be measurable and trackable. These goals could include achieving schedule and budget targets, delivering committed functionality that satisfies acceptance tests, complying with industry standards or government regulations, or achieving specific technology milestones. The business objectives define the overarching goal. It doesn’t matter if you deliver to the specification on schedule and budget if those factors don’t clearly align with business success.

Not all of these defined success criteria can be your top priority. You’ll have to make some thoughtful tradeoff decisions to be sure that you satisfy your most important priorities. If you don’t define clear priorities for success, team members can work at cross-purposes, which leads to frustration, stress, and reduced effectiveness. Chapter 4 of Practical Project Initiation presents a tutorial on defining project success criteria.

Practice #2: Identify project drivers, constraints, and degrees of freedom.
Every project must balance its functionality, staffing, budget, schedule, and quality objectives. Define each of these five project dimensions as either a constraint within which you must operate, a driver strongly aligned with project success, or a degree of freedom you can adjust within some stated bounds. I explain this idea more fully in my book Creating a Software Engineering Culture (Dorset House, 1996).

I’m afraid I have bad news: not all factors can be constraints, and not all can be drivers. The project manager must have some flexibility to react to schedule slips, demands for more functionality, staff turnover, and other realities.

I once heard a senior manager and a project leader debate how long it would take to deliver a planned new large software system. The project leader’s top-of-the-head guess was four times as long as the senior manager’s stated goal of six months. The project leader’s response to the senior manager’s pressure for the much shorter schedule was simply, “Okay.”

A better response would have been to negotiate a realistic outcome through a dialogue:

How critical is the six-month goal? Does something drastic happen if we don’t deliver in six months (schedule is a constraint), or is that just a desirable target date (schedule is a driver)?
If the six months is a firm constraint, what subset of the requested functionality do you absolutely need delivered by then? (Features are a degree of freedom.)
Can I get more people to work on it? (Staff is a degree of freedom.)
Do you care how well it works? (Quality is a degree of freedom.)
Can I get more funding to outsource part of the project work? (Cost is a degree of freedom.)

While teaching a project management course once, a student insisted that all five dimensions were constraints on her project. She had a defined feature set that had to be delivered with zero defects by a specific date by a fixed team size working on a fixed budget. The likely outcome? She will most likely fail. An overconstrained project has no way to deal with requirement changes, staff turnover or illness, risks that materialize, or any other unexpected occurrences.

Practice #3: Define product release criteria.
Early in the project, decide what criteria will indicate whether the product is ready for release. Some examples of possible release criteria are:

There are no open high-priority defects.
The number of open defects has decreased for X weeks, and the estimated number of residual defects is acceptable.
Performance goals are achieved on all target platforms.
Specific required functionality is fully operational.
Quantitative reliability goals are satisfied.
X% of system tests have been passed.
Specified legal, contractual, or regulatory goals are met.
Customer acceptance criteria are satisfied.

Whatever criteria you choose should be realistic, objectively measurable, documented, and aligned with what “quality” means to your customers. Decide early on how you will tell when you’re done, track progress toward your goals, and stick to your guns if confronted with pressure to ship before the product is ready for prime time. See Chapter 5 of Practical Project Initiation for more about defining product release criteria.

Practice #4: Negotiate achievable commitments.
Despite pressure to promise the impossible, never make a commitment you know you can’t keep. Engage in good-faith negotiations with customers, managers, and team members to agree on goals that are realistically achievable. Negotiation is required whenever there’s a gap between the schedule or functionality the key project stakeholders demand and your best prediction of the future as embodied in project estimates.

Principled negotiation involves four precepts, as described in Getting to Yes by Roger Fisher, William Ury, and Bruce Patton (Penguin USA, 1991):

Separate the people from the problem.
Focus on interests, not positions.
Invent options for mutual gain.
Insist on using objective criteria.

Any data you have from previous projects will strengthen your negotiating position, especially because the person with whom you’re negotiating likely has no data at all. However, there’s no real defense against truly unreasonable people.

Plan to renegotiate commitments when project realities (such as staff, budget, or deadlines) change, unanticipated problems arise, risks materialize, or new requirements are added. No one likes to have to modify his commitments. But if the reality is that the initial commitments won’t be achieved, let’s not pretend that they will right up until the moment of disappointing truth. I discuss the importance of negotiating achievable commitments in Chapter 9 of Practical Project Initiation.

These four practices can help you get your project off to a solid start, with a clear idea of where you’re headed. In Part 2 of this series we’ll take a look at eleven best practices for planning the project.

Don’t forget to leave your comments below.

Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is a memoir of life lessons titled Pearls from Sand: How Small Encounters Lead to Powerful Lessons.

So What?

Written by Kiron Bondale on December 14, 2011. Posted in Articles. 11 Comments on So What?

As we know, 80-90% of a project manager’s time is spent communicating. The challenge for some project managers is that their communication appears to fall on deaf ears. Team members don’t follow established procedures for status reporting or issue notification and senior stakeholders procrastinate or avoid decision making, issue resolution or risk response execution.

When asked, the project manager might point to minutes from meetings, project status reports and e-mail messages to prove that the requests were made. Sadly, this ignores a core principle of the basic communication model as per the PMBOK Guide, 4^th edition: “the sender is responsible for making the information clear and complete so that the receiver can receive it correctly, and for confirming that it is properly understood”.

If the message encoding the information the project manager is hoping will generate action is not perceived by the receiver to be as important or urgent as the project manager feels, the outcome will not be the expected one.

The project manager may wish to have team members follow certain “common sense” steps for sharing information or for escalating appropriately but if the impact of their not doing so is not clear to them, the team members are likely to perceive this as bureaucracy or micro-management.

If the project manager takes the time to explain the linkage between the requested information and gaining greater predictability on achieving the project’s objectives and is successful in communicating how the success of the project aligns with the success of the team members, they are likely to at least understand what’s in it for them and why it is important to the project. This does not guarantee 100% compliance, but at least expectations were appropriately set.

With senior stakeholders such as a project sponsor, a different challenge presents itself. If the project manager cannot clearly articulate the business impacts of a decision, issue resolution or risk response, at best, the senior stakeholder will procrastinate, but worse, this poor communication will impact the stakeholder’s perception of the professionalism and effectiveness of the project manager.

While observing the body language or verbal reactions of senior managers to a project manager who is clearly missing the mark with their communication attempts, I’ve often mentally drawn cartoon bubbles over the senior stakeholders’ heads with the thought “Why are they wasting my time?”.

Even if the project manager clearly explains the business impacts of not fulfilling a request, it may still not be perceived as a high enough priority. Sometimes, there is nothing more that the project manager can do in this case beyond further escalation but if there is the potential of a downstream impact to other more critical business outcomes, it is the responsibility of the project manager to help the senior stakeholder understand these ripple effects.

It would be wonderful if Star Trek’s Universal Translator existed, but until it does, project managers who are unable to answer the “So What?” question might suffer the same fate as an average red shirted crew member!

Don’t forget to leave your comments below.