There is no doubt that managing the expectations of stakeholders throughout the project life cycle is critical to the success of the project. Successive project surveys consistently highlight the importance of stakeholder management integral to project success. Furthermore, there is a plethora of literature on how to identify and engage stakeholders during the course of the project work, and how to effectively manage stakeholders to influence project outcomes.
However, the existing literature on stakeholder management is of little use, especially when it comes to very large complex projects, where a multitude of stakeholders are engaged-many of them from diverse backgrounds and different nationalities.
What exacerbates the management of stakeholder expectations is that some stakeholders choose not to voice their expectations, and if they do they are extremely ambiguous about what they want from the project, and to what extent they are willing to provide support to the project team. Additionally, stakeholders are quick to seek refuge in the organisation’s political correctness culture to conceal their real motives, thereby impeding the progress of the project.
On time. On budget. Error free. These are crucial delivery goals for any organization. Yet they are rendered almost meaningless if the product fails to deliver value.
That’s why successful delivery teams work hand-in-hand with their stakeholders as product partners, defining value and then actively discovering — and delivering — high-value solutions. This goes beyond feature requests and requirements documents—beyond user stories and product backlogs—beyond the push-pull of competing interests. It’s a partnership where the ideas, perspectives and experiences of three different stakeholder groups converge. The result? Product partners who collaborate to discover and deliver value.
Let’s look more closely at these product partners: who they are, how they work together, and how they balance competing priorities.
First Ask Who
A product partnership includes people from three realms: customer, business, and technology. Each offers a unique perspective and has its own ideas of what is valuable.
The customer partners represent users, buyers, and advisers — people or systems that interface with the product, choose to buy it, or influence others to buy it. They tend to value improved productivity, heightened efficiency, greater speed, entertainment, and similar benefits.
It is well known that a strong cohesive team is an effective and productive team. But how does one convert a gaggle of employees into a successful team? Professionals, scholars, and writers have answered that question time and time again. Strategies including team-building exercises, retreats, luncheons, touchy feely sessions, and so forth have all proved effective in developing a cohesive team over time within a functional organizational structure. However, time to build a cohesive team is not a luxury that exists in a matrix style organization where a group of individuals are put together for what may be a short specific project. This article will focus on techniques that can be utilized to build a successful team in a versatile matrix organization thus mitigating some of the risks associated with continuously jumbling team members from project to project.
A matrix structure within an organization utilizes cross-functional teams comprised of personnel from various disciplines in support of a common project. This differs from the traditional hierarchical (functional) organizational structure by:
- Blending various skills into a single team under a project manager
- Teams works together only for the duration of a project
- Members come and go from the team as needed to support project
The matrix structure is a proven blend of the traditional functional and projectized structures and allows management team to slide personnel around to meet needs on projects as they arise.
In the above example, an organization is setup with three functional areas: logistics, training, and technical support. Whenever a new project is initiated, a project manager is assigned resources from the appropriate functional area as needed. Project Manager #1 requires support from logistics and technical support where as Project Manager #3 requires support from all three functional areas.
“Are you a process person”? Have you ever been asked that, perhaps at a job interview? I, thankfully have not. I have, however been told by other people that they are “a process person.” Usually when I am told this, it is with a sense of pride or affirmation. The question then occurs to me, “What is a process person”? I think that most people would agree to the following definition:
“Someone who utilizes documented and repeatable processes to achieve a goal or result.”
By this definition, I consider myself a process person. However, there is another definition, a definition “of practice.” I have come to the following definition of what a process person is by real-world observation of self-described “process people.”
“Someone who focuses totally on process. Someone who sees the process as the end result and defines success as the successful implementation of the process.”
Some will read this second definition and be confused. Many will read it and say to themselves, “But if the process is implemented correctly, then the goal(s) is achieved.” When stated in this manner, the fallacy of this statement is fairly obvious. A process is a means to an end, not an end unto itself. Still many people define the success of their projects by the processes they incorporate.
Change, what is it? What is its purpose?Change is not some random event. Change is about status quo. It is the planned movement from the current status quo to some new status quo. Change, like a project, is transitional. It is the transition between two stable status quos, the current and the desired. Since change is not random, it is initiated by someone and affects others. A single change has multiple impacts. It’s not enough to understand just the nature of the change. We also need to understand the nature, target, and consequence of the stakeholder impacts.
There are three key conditions in Change Management that we need to understand and address:
- Single changes create multiple stakeholder impacts. A new status quo can lead to stakeholders experiencing one or more of the following consequences:
- They can be better off.
- They can be worse off.
- They can be unaffected.
- Stakeholder perception of the impact may be different from the reality. Each stakeholder will respond based on his perception of the project impact. Therefore, it’s critical for the change manager to understand each stakeholder’s perception versus reality.
- Stakeholder management and planning must take account of both the reality and the perception, for the change to succeed.
Often in the hectic world of Project Management the quick compromise fits the bill. It’s quick, efficient and gets the job done. But is it the best solution?
Every Project closure needs a time for lessons learned. Alas I am not the only one who sees the same mistakes repeated far too often.
One of the most oft repeated mistakes I see in negotiation and conflict management is the over use of compromise. It is almost accepted practice to split the difference and move on. People think the correct answer is half way between the two positions.
It is not.
If an agreement is made and the parties can smile afterwards some think this is a win-win.
It is not.
Compromise is really a competitive negotiation because it is based on positions not the underlying interests.
Whether it is a Project Management timeline, Government shut down or Middle East peace negotiations, a collaborative process is essential to having a true win-win outcome. Quick and efficient is not the same as a solution that truly satisfies the needs and interests of both parties. Not damaging the relationship of the two parties in a negotiation is not the same as building trust and engaging in a collaborative negotiation methodology.
In the previous three articles in this series, I’ve described seventeen practices the project manager can apply to lay the foundation for a successful project, plan the project, and estimate the work to be done. In this final article I share three good practices for tracking your progress throughout the project and one practice for learning how to execute future projects more successfully.
Tracking Your Progress
Practice #18: Record actuals and estimates.
Unless you record the actual effort or time spent on each project task and compare them to the estimates, your estimates will forever remain guesses. Someone once asked me where to get historical data to improve her ability to estimate future work. My answer was, “If you write down what actually happened today, that becomes historical data tomorrow.” It’s really not more complicated than that. Each individual can begin recording estimates and actuals, and the project manager should track these important data items on a project task or milestone basis. In addition to effort and schedule, you could estimate and track the size of the product, in units of requirements, user stories, lines of code, function points, classes and methods, GUI screens, or other units that make sense for your project.
Practice #19: Count tasks as complete only when they’re one hundred percent complete.
We tend to give ourselves a lot of partial credit for tasks we’ve begun but not yet fully completed: “I thought about the algorithm for that module in the shower this morning, and the algorithm is the hard part, so I’m probably about sixty percent done.” It’s difficult to accurately assess what fraction of a sizable task has actually been finished at a given moment.
As Product Managers, we are responsible for executing on the overall strategy and roadmap for our products. We develop roadmaps that maximize business value, we recognize market trends, we identify opportunities, we create timelines and we communicate our goals to developers and testers.
Modern product delivery has embraced more iterative development processes; this was supposed to make our jobs easier by breaking work into smaller chunks that customers can validate sooner. Despite its numerous benefits, the pressure to get to market faster, without any impact on quality, has actually exacerbated several common frustrations:
- Balancing Conflicting Priorities Across the Business to Define a Roadmap
- Accelerating Product Innovation and Delivery
- Keeping Teams Aligned
I’m writing – you are reading - WE are not communicating. Not yet anyways. Communication comes from the Latin, which means ‘to come to a common understanding’.
Re-Learning how to communicate in a fast moving race down the ever-lengthening TO-DO list or e-mail inbox greatly increases efficiency, avoids mistakes, decreases risk and avoids conflict.
Every Project closure needs a time for lessons learned. Alas I am not the only one who sees the same mistakes repeated far too often. The way we communicate – that is come to that common understanding is the most efficient way to solve problems and keep them solved. Unfortunately, work-arounds and compromise seem to be the norm.
The reality of a jury trial is different from what we see on TV or read in books, where the action moves quickly towards the acquittal or conviction of the defendant. On TV the opening arguments, the witness interrogation, and the closing arguments are all pertinent and exciting. Of course, on TV and in books trials are filled with action, with both sides winning points, stumbling, and articulating coherent and often poignant arguments. Oh, the fast-paced drama of it all.
So when I was summoned for jury duty, my expectation was that while there might be some down time waiting to be selected for a jury panel, once picked, things would move along quickly. Reality, not surprisingly, proved quite different. Perhaps some trials are filled with drama, interesting cross-examinations, and surprise endings. But my experience as a jury panelist was, for the most part, all about waiting.