Project Management : Interesting Terminologies

PMs are the most creative pros in the world; they have to figure out everything that could go wrong, before it does.

There are many project management principles and methodologies in places. Recently while discussing about some interesting terminologies with one of my mentor I came across very funny jargon's/ principles available in project development life cycle. This blog is a collection of such jargon's which we can start using in our day-to-day project management practices.

a) Watermelon Project

As the name suggest your project is green from outside (generally in status report with no issues) where as actually red from inside (there are serious issues). This usually occurs for various reasons, e.g. PM thinks project in red will increases the risk that it will be canceled. It may embrace for a PM to admit that their project is not going as well as it could/should be. Or the problem really should have been reported (perhaps as amber) some time ago, and to report it as red now would expose that it wasn't reported amber before. These are reflection of poor management.

How to avoid - The See-through Watermelon - The best measure of project success is showing a working solution. Agile Project Management emphasizes regular demos of potentially shippable product. By ensuring that senior stakeholders can see tangible progress that will increase their confidence that your project can overcome issues that it encounters.

Life is like eating a watermelon, you know you're going to get some seeds; just spit them out and take another bite.

b) Bus Number (Bus factor)

The term is mostly used in business management, and especially in the field of software development. The "bus factor" is the minimum number of team members that have to suddenly disappear from a project before the project stalls due to lack of knowledgeable or competent personnel.

The bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members, from the phrase "in case they get hit by a bus". It is also known as the lottery factor, truck factor, bus/truck number, or lorry factor. And of course, that don’t have to be necessarily hit by a bus: illness, vacation, and departure from the company are all frequent occurrences that can bring disaster to a project.

How to calculate Bus factor - For instance, say a team of 10 people produces bread in three necessary steps: mixing ingredients, kneading the dough, and baking. 6 people know how to mix ingredients, all 10 people know how to knead the dough, and 3 people know how to bake. If all 3 people who know how to bake disappear, then the team cannot produce bread, so the team's bus factor is 3.

How to Increase Bus Factor - In many software development projects, one of the goal is to share information in order to increase the bus factor to potentially the size of the entire team. A high bus factor is considered a good thing as it means that many individuals know enough to carry on and the project could still succeed even in very adverse events.

Several ways to increase the bus factor have been proposed:

1) Reduce complexity

2) Document all processes and keep that documentation up-to-date

3) Encourage cross-training.

So What's your Bus Number ?

c) Kipper Management

This is the manager who is, like a fish, two-faced because employees can see only one face at a time. To senior managers, this person is typically a model employee who puts business first and himself last. To subordinates, however, the reverse is often the case. The subordinates will work hard to get things done in time, but they are blamed when things go wrong—even if it is not their fault. The kipper will be a friend when things need to get done and then stab the subordinates in the back when glory or reward is to be gained.

Historically, the kipper may have been taught that 'this is how it works'. If you are a more senior manager and suspect you have a kipper in your ranks, get 360 degree views on them from different people. 

d) Software Peter Principle

The Software Peter Principle is used in software engineering to describe a dying project which has become too complex to be understood even by its own developers.

It is well known in the industry as a silent killer of projects, but by the time the symptoms arise it is often too late to do anything about it. Good managers can avoid this disaster by establishing clear coding practices where unnecessarily complicated code and design is avoided. The name is used in the book C++ FAQs, and is derived from the Peter Principle – a theory about incompetence in hierarchical organizations.

e) Gold Plating (project management)

Gold Plating in Project Management means giving the customer extra or more than the actual requirement. Gold Plating is unethical and not allowed as per the Project Management Code of Conduct. 

For example: after having met the requirements, the project manager or the developer works on further enhancing the product, thinking the customer will 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 a bad project management practice for different project management best practices and methodologies such as Project Management Body of Knowledge (PMBOK) and PRINCE2.

It can be avoided at the time of preparing the detailed scope statement or statement of work (SOW) by ensuring that unwanted material or work are not taken into account and then have a proper Scope Management Plan to review and change the SOW at any stage of the project if it is felt that gold plating has taken place knowingly or unknowingly.

f) Seagull Manager

Seagull management is a management style wherein a manager only interacts with employees when they deem a problem has arisen. The perception is that such a management style involves hasty decisions about things of which they have little understanding, resulting in a messy situation with which others must deal. Seagull managers fly in, make a lot of noise, dump on everyone, then fly out.

As seagull managers only interact with employees when there is a problem, they rarely offer praise or encourage when things are going well. When problems arise, they often seek to place the blame on other people,and to draw attention to themselves in order to appear important. They criticize others, but make little contribution to the solution of a problem.

The seagull style of management may be indicative of a manager who is untrained, inexperienced or newly-appointed. If you are a manager, then seagull management is of course something to avoid. It is a trap that may seem easy but in practice it will alienate and demotivate your staff. If there are wiser people above you, then they also will find out what is happening and your advancement will halt or regress.

g) Single Wringable Neck - Agile

In Scrum one of the named roles is that of Product Owner. Some people have taken to referring to this position as the “single wringable neck” on a Scrum team. This is because the Product Owner is ultimately responsible for the prioritized product backlog which the team uses as their to-do list to build the product. If the Product Owner does a poor job then the resulting product will not meet customer needs. That scenario leads people to believe that the Product Owner will face the music if project failed. 

I don’t agree with the single wringable neck concept. I believe a team creates products and all members of the team contribute. A Product Owner may ultimately be one of the major contributing factors to failure, but it is rarely the only one.

h) Boondoggle Project

A Boondoggle is a project that is considered a waste of both time and money, yet is often continued due to extraneous policy or political motivations.

For Example - The Sydney Opera House could probably be seen as one of the most disastrous construction projects in history not only from the financial point of view but also for the whole management plan. The project was originally scheduled for 4 years, with a budget of AUS $7 million. It ended up taking 14 years to be completed and cost AUS $102 million.

But later this architecture considered as Successful boondoggles - the cost of construction of the Sydney Opera House ballooned over 1,400 percent, but the building has since become an icon for the city and for Australia.

i) Dogfooding - Product Management

The term "dogfooding" is an IT slang for the use of one's own products. In some uses, it implies that developers or companies are using their own products to work out bugs, as in beta testing. One benefit of dogfooding is that it shows that a company is confident about its products.

The initial use of the term dogfooding is often traced back to Microsoft manager Paul Maritz, who, in 1988, used it to challenge Microsoft's internal employees to use the company's products.

j) WAG estimation - SWAG

A WAG (wild-a$$ guess) is an off-the-cuff estimate for something, such as the completion date of a project, when there is insufficient data available to support a more informed estimation. In Agile and scrum software development, a WAG is often based upon historical experience. Planning poker, a team building activity for achieving group consensus, is a popular tool for creating WAGs that are more likely to be realistic.

SWAG is an acronym meaning “Sophisticated Wild A$$ Guess”. It is used in the military world as well as in the software development discipline. It basically means that there is not enough time or information to deliver an exact estimate of what is needed, and as a consequence, an estimate is made based on what is available, be it part of the required information, be it nothing. The term is mainly used in the US, and it is not an official PMI term.

k) Hubristic Management

'Hubris' The characteristic of excessive confidence or arrogance, which leads a person to believe that he or she may do no wrong. The overwhelming pride caused by hubris is often considered a flaw in character. Hubristic management is a dangerous cocktail of overconfidence, overambitious, arrogance and pride fueled by power and success.

First, never rest on your laurels. Nokia got to the top of its industry quickly. But once there, it became complacent in an industry where laziness is fatal. It worried too much about hanging on to its market share, rather than creating new products to excite customers.

Examples are drawn from business and politics including Lehman Brothers, RBS, BP and Deepwater Horizon, Blair and Bush in the Iraq Invasion, NASA, and, of course, the leadership of Donald Trump.

l) Death March Project

In project management, a death march is a project that the participants feel is destined to fail, or that requires a stretch of unsustainable overwork. The general feel of the project reflects that of an actual death march because project members are forced to continue the project by their superiors against their better judgment. Software development and software engineering are the fields in which practitioners first applied the term to these project management practices.

Death marches of the destined-to-fail type usually are a result of unrealistic or overly optimistic expectations in scheduling, feature scope, or both, and often include lack of appropriate documentation or relevant training. The knowledge of the doomed nature of the project weighs heavily on the psyche of its participants, as if they are helplessly watching themselves and their coworkers being forced to torture themselves and march toward death. Often, the death march will involve desperate attempts to right the course of the project by asking team members to work especially grueling hours.

m) Mushroom Management

Mushroom Management, also known as Pseudo-Analysis or Blind Development, is a mocking term used to describe the running of a company or project where the communication channels between the managers and the employees do not work properly. The term alludes to the stereotypical (and somewhat inaccurate) view of mushroom cultivation: "Kept in the dark and periodically given a load of manure".

For example most of the scam or scandals in past (Enron, Lehman Brothers, Satyam, Worldcom etc.) are part of mushroom management.

The main reasons for the development of mushroom management within a company can be found at the managerial level. Mushroom management often develops when managers see themselves as the sole decision-makers within the company, rather than the people who lead all the employees towards a shared success.

Conclusion:

Life of a project manager can be tough, if anyone needs inspiration to keep going with leading our projects and teams, it’s us. When you find yourself (or your project) constantly slamming into one brick wall after another it is always advisable to stay positive and focused. Project Management is, above all, a practice where art, science, and craft meet. They know very well that first 90% of a project takes 90% of the time, the last 10% takes the other 90%. isn't it ?

There are no good project managers - only lucky ones. The more you plan the luckier you get.

Credit : wikipedia.org, changingminds.org, newsweek.com, www.strategy-business.com, pmi.org