What is the Salience Model in Project Management?

What is the Salience Model?

Every project has many stakeholders. Each project stakeholder has varying expectations. Stakeholder prioritization can be a nightmare. Managing the communication needs of the various project stakeholders is a tricky. Let’s see how the Salience Model helps put project stakeholders into perspective.

    Introduction

    The Salience Model for project stakeholders was developed by Mitchell, Agle, and Wood to help managers identify and analyze project stakeholder needs. Unlike, the Power/Interest or Power/Influence grids, the Salience Model uses three parameters to categorize stakeholders: Power, Legitimacy and Urgency. Each parameter is defined as follows:
        Power: Is the ability project stakeholders has to influence the outcome of an organization, deliverables, or a project
        Legitimacy: Is the authority, level of involvement project stakeholders have on a project.
        Urgency: Is the time expected by project stakeholders for responses to their expectations.

    This three-dimensional view of project stakeholders needs and expectations from a project can help managers narrow down the critical stakeholders for stakeholder management.
 
    The Salience Model Diagram

    The Salience Model for project stakeholders is graphically depicted as a Venn diagram. Each assessment parameter has a major circle and the intersections of each major circle helps you identify project stakeholders that have multiple needs.




Mitchell, Agle, and Wood related each area within the Venn diagram to a specific type of stakeholder. Mentioned below is a description of each type of project stakeholder as per the Salience Model:

A) Core/Definitive: These are the critical project stakeholders. As a Project Manager, you need to provide focused attention to these stakeholders.

B) Dominant: Such project stakeholders have power and legitimacy, but do not have urgency. You should focus on their expectations, but always there is not a lot of urgency.

C) Dependent: As per the Salience Model, these project stakeholders have no real power on the project. However, they need to be managed because they can quite easily choose to align themselves with other project stakeholders and hence influence your project.

D) Dangerous: Appropriately named classification, these stakeholders have power and urgency, but no legitimacy. Imagine a very senior person trying to force her views on the outcome of your project, without really being a part of it! A Project Manager needs to keep such stakeholders appropriately engaged or satisfied.

E) Latent/Dormant: Possibly the best category project stakeholders. These stakeholders only get into the project, if there is something has gone horribly wrong with it. Over-communication of micro-level details with them is also not a great thing to do.

F) Demanding: Such stakeholders in the Salience Model are people that always seem to think that their work needs your immediate attention. If you spend too much time and effort on these stakeholders, you won’t actually gain to much project mileage. There are other more important people to work with.

G) Discretionary: Another wonderful classification of project stakeholders. Give them regular status updates and they’ll be happy.

H) Non-stakeholders: These people are not stakeholders in the project. Investing time and effort on such people will not help you shape the outcome of your project in any manner.

Pareto's law in Project Management

CAPM Test Question/PMP Test Question regarding Pareto's Law

12. What is Pareto's Law?

A.     80% of the effects come from 20% of the causes B.     Work expands so as to fill the time available for its completion. C.     Anything that can go wrong will go wrong. D.     Never attribute to malice that which can be adequately explained by stupidity.

Answer: A - Pareto's Law says that 80% of the effects come from 20% of the causes. Vilfredo Pareto, an Italian Economist, observed in his country that twenty percent of the people owned eighty percent of the wealth. The poor were lucky then - today it's more like 10/85. Management thinker Joseph Juran (1904 - 2008!) was the one who actually came up with this concept as it applies to business and named it after Pareto. We’ll go through the other ones since they’re kind of fun to know: B, "Work expands so as to fill the time available for its completion" is Parkinson's Law. That's another good one to know. C, is Murphy's Law. Sometimes it may seem like "Anything than can go wrong will", but it isn't necessary a good philosophy to have! D, "Never attribute to malice that which can be adequately explained by stupidity." is Hanlon's Razor. This isn't in the project manager's handbook for good reason. It's easier to work with a team when you have a healthy respect for them. Nevertheless, you can keep this in the hip pocket for an opportune time. Key Takeaway: This is a handy heuristic to help you focus your attention on the most important things a project entails, allowing him/her to manage key risks and satisfy the most important stakeholders. Other examples: 20% of your customers will cause 80% of you problems. 20% of items in inventory represent 80% in sales. And so on. One application I'm sure you'll find interesting is that 80% of beer is drunk by 20% of consumers. That's why most beer commercials are concentrated on football and tawdry men's magazines. It just makes sense for those companies to focus on their heavy consumers.

Gold-plating in Project Management

I came across a new project management term today called "Gold plating" in a CAPM Test question. Had never come across this term before so I looked up the definition.

Gold plating in software engineering or Project Management (or time management in general) refers to continuing to work on a project or task well past the point where the extra effort is worth the value it adds (if any). After having met the requirements, the developer works on further enhancing the product, thinking the customer would be delighted to see additional or more polished features, rather than what was asked for or expected. The customer might be disappointed in the results, and the extra effort by the developer might be futile.

Gold plating is also considered as a bad project management practice for different project management best practices and methodologies such as: Project Management Body of Knowledge (PMBoK) and Prince 2. In this case, gold plating refers to the addition of any feature not considered in the original scope plan (PMBoK) or business case (Prince2) at any point of the project since it introduces a new source of risks to the original planning i.e. additional testing, documentation, costs, timelines, etc. However, gold plating does not prevent new features from being added to the project, they can be added at any time as long as they follow the official change procedure and the impact of the change in all the areas of the project is taken into consideration.

The CAPM test question is as below: 

Mr. Thompkin's Journal from Death March by Tom Demarco

Mr. Tompkins, a manager downsized from a giant telecommunications company, divides the huge staff of developers at his disposal into eighteen teams--three for each of the software products. The teams are different sizes and use different methods, and they compete against each other and against an impossible deadline. With these teams--and with the help of numerous "fictionalized" consultants who come to his aid--Tompkins tests the project management principles he has gathered over a lifetime. Each chapter in the book Death March by Tom Demarco closes with journal entries that form the core of the eye-opening approaches to management illustrated in this entertaining novel. This is my reflection on the journal entries of Mr. Tompkins from Death March.

Mr. Tompkin's Journal packages a concise collection of insightful project management principles, approaches, skills and best practices and summary points for review. Each journal entry presents a series of conclusions for new scenarios discussed in the chapter. It covers a broad array of technical subjects like risk management, project estimating, metrics, improving productivity, overstaffing effect, dealing with ambiguous specifications, modeling for simulation, process improvement as well as soft skills such as leadership, interviewing and hiring project staff, motivating performance, improving communication, team politics, team dynamics, anger management, conflict resolution and negotiation.

Most project management books and guides focus on the technical aspects of project management processes. However, the journal entries emphasize that it is the people along with the processes that are the indispensable foundation of any successful project. An interesting point that the journal mentions which I had not come across in any other project management book is in the “Playing Defense” entry: “Keep good teams together to help your successors avoid problems of slow-jelling or non-jelling teams. Think of a jelled team as one of the project deliverables”. In my previous organization, it was a policy to disperse the project team to different projects or even different department domains (from insurance to banking) once the project is complete. Sometimes, the resources would even be shuffled between projects while the project is still going on, which would put additional strain on the project team to get the new resource on-level. I believe that when resources are transferred between domains, the existing domain knowledge of the resource is wasted.  So, I completely agree that a jelled team is the most important resource and should be considered as one of the deliverables. This is especially true in bigger projects that last for more than a year, unless you are dealing with a geographically dispersed team (GDT), because of the time invested in promoting trust and making certain that everyone knows their contribution.

Another journal entry that I had not come across before in any other book was about “Negative Reinforcements”: “Threats are an imperfect way to motivate performance

No matter how serious the threat, the work still won’t get done on time if the time originally allocated for it was not sufficient”. This reminded me of one of my earlier projects which had stringent deadlines and the scope of the project increased because of requirements not being properly documented. The upper management made it clear that unless the team put in more hours during weekdays we will have to work on weekends. Not only, did the entire team have to put in more hours during weekdays, but we spent three consecutive weekends trying to meet the deadline, which ultimately had to be extended, which I think goes to prove another journal entry that “The real reason for use of pressure and overtime may be to make everyone look better when the project fails”.

The best part about the journal was that, apart from the realm of software and projects, it also offers some practical, positive, and philosophical advice such as “You can’t get people to do anything different without caring for them and about them. To get them to change you have to understand and appreciate where they’re coming from and why”. This is applicable not only to the project scenario, but also to life in general. The one I liked the most is “There are infinitely many ways to lose a day, but not even one way to get one back.” because sometimes people have a tendency to procrastinate and finish work at the last minute.

Thus, I think Mr. Tompkin’s journal helped me in comprehending a lot of important project and process concepts and made me think how I would react to certain situations and also to obtain a perspective about interacting with people while working in a team.

Project Management Death March Reflection

 

The book ‘Death March’ starts by introducing death march project concepts, exploring
various causes and explaining why people participate in such projects. After having
worked on one such project, I have experienced first-hand almost all of the causes and
effects of a death march project that the author mentions.

A study of over 7000 development projects cited in the 1997 edition of Computerworld,
stated that 55% were over budget (with cost overruns of more than 50%), 50% were late
(needing at least twice the estimated time), and 30% were incomplete (the product was
delivered with 50% or less of the planned functionality). These statistics were taken a
decade ago. So as I began reading the book, I thought that in the end, the author would
conclude that death march projects are likely to diminish because the industry is more
aware. But I was rather surprised that the author actually maintains throughout the book
that death march projects are the norm and will continue to be so, which was thought-
provoking.

The "politics" and "negotiations" chapters were engaging with ample lessons to be learnt.
I did not expect politics to be such an important factor in running a project smoothly.
What was interesting to read is the author’s description of death march projects from
differing perspectives of the key players namely the Owner, Customer, Shareholder,
Stakeholder, Champion. It made me realize the role and importance of a Champion.
Also, the negotiation games described were pragmatic. I understood how crucial
negotiations can be to a death march project and how they can be put to practice to
avoid projects from becoming death march projects such as the ‘Two out of three (cost,
schedule, quality)’ rule or the ‘10% change in project variable’ rule.

The thing I liked most about the book is that the author makes candid observations
about death march projects. The author mentions that some of the effects of a death
march project are lower self esteem, depression, and anxiety which I too have come
to witness while working on a death march project. Throughout the book the author
actually presents pragmatic ways of dealing with a death march project such as
not becoming too emotionally attached to the outcome of the project. I enjoyed
reading analogies that the author uses to compare death march projects such as
underground mining, cowboying, high rise window washing and the epitome –
spending a night in jail.

Almost everyone in the computer industry has noticed their workload increasing, while
at the same time the deadlines imposed by their supervisors are shortening. from a very
personal perspective of an individual member. In other words, a death march is just about
every project in these crazy days of compressed development cycles.

This book can be a very good tool to maintain a sense of perspective and help appreciate
the concerns of non- developers involved with the project.

The book then goes on to cover such significant topics as how a Death March project
team leader should negotiate with management for budget, working conditions, staffing,
etc.; how to handle the day-to-day issues of working on such a project, and, just as
importantly, when to know when it's time to get out.

I found this book to be remarkably refreshing in dealing with the true issues of working
in these sorts of environments, and it is far more practical than I had expected it would
be. The book has a Utilitarian approach. It is clearly written by someone who has "been
there" and has no use or time for trite answers. It would have been interesting to see some
of the examples in the book extended along these lines.

It is certain to occasion thousands of thoughtful debates all over the world. At the very
least, it will provide a great deal of practical advice for those "on the march" right now,
as well as at least some measure of relief by letting the participants know that they're not
alone.

In conclusion, I would say that the book adopts a very utilitarian perspective and
provides valuable guidance in identifying a death march project, understanding the
reasons behind it and the effects of it. The book also provides practical advice about
making an educated decision whether to get involved in a death march project or
not.

It hasn't stopped death march projects from taking place. And that death march projects
are likely to diminish. Death march projects are likely to be a common occurrence for
years to come. And that's the primary point of this chapter. You may not agree with any
of the rationales suggested here; you may not like any of the reasons for initiating such
projects or joining such projects—but they're real nonetheless. that such projects can be
an educational experience even if they fail

The books starts by exploring death march project concepts, introducing various causes
and reasons why people would join them. After looking at such projects from a very
personal perspective of an individual member, the author then presents several other

viewpoints - from the perspective of corporate politics and from the perspective of other
people involved in the death march team.

Although my personal experiences are different from one of the key ideas of the book,
that ‘death march projects are the norm, not the exception‘, I recognised several of my
projects in the descriptions of ‘mission impossible‘ and ‘ugly‘. Death March is quite a
thought-provoker, and it made me revisit my own dark experiences, thinking about what
we did and how we did it, why projects succeeded and failed, where we were wrong and
how not to do it again. Case studies in this book discuss problems common in software
development, so the proposed solutions are a good starting point for ideas that can be
applied to improve typical projects.