WIIFM - What's In It For Me

I remember sitting through some of my directors' presentations listening to them talk about, What's In It For Me, or WIIFM for short (not to be confused with the Nintendo Wii - which I play but suck at.) The basic idea was while you worked hard on projects you were also learning, developing new skills and getting new experiences. WIIFM for everyone!

In a few of my blog posts I've written about how important it is to adjust your presentation and communication to your audience. In effect, you were telling them, What's In It For Them. It's all about creating a relevant experience to sell an idea, product or concept.

Now let's step back and examine this WIIFM concept applied to another situation. Have you ever worked on a project where you have an idea on how more success can be achieved if the project team were to work more collaboratively with other project teams and personnel? In my experience the typical project manager response is, "It's not my problem," or, "It's outside of my scope," or, "It's someone else's problem." Then you step back and watch the car crash in slow motion; the problem manifests itself and severely impact the project and company as a whole.

I liken this to Adam Smith's (the Father of Economics) "invisible hand."

As every individual, therefore, endeavors as much as he can both to employ his capital in the support of domestic industry, and so to direct that industry that its produce may be of the greatest value; every individual necessarily labors to render the annual value of society as great as he can. He generally, indeed, neither intends to promote the public interest, nor knows how much he is promoting it. By referring the support of domestic to that of foreign industry, he intends only his
own security; and by directing that industry in such a manner as its produce may be of the greatest value, he intends only his own gain, and he is in this, as in many other cases, led by an invisible hand to promote an end which was no part of his intention. Nor is it always the worse for the society that it was no part of it. By pursuing his own interest he frequently promotes that of society more effectually than when he really intends to promote it. I have never known much good done by those who affected to trade for the public good. It is an affectation, indeed, not very common among merchants, and very few words need be employed in dissuading them from it. (Adam Smith, The Wealth of Nations)

Basically, this means each individual acting in his (or her) own self-interest will lead to a better outcome for the society as a whole; or WIIFM but on a project-scale. The problem with this is simple. No one ever builds roads and the infrastructure to connect things because it's in no specific person's best self-interest; but that's not my problem. Is it?

I'm not saying expand a project's scope, merely understand how a project fits in with the big picture.

Tips for end-user acceptance

Any solution, no matter how well it has been conceived will not be successful unless it is embraced by its intended end-users. Here are some quick tips to help promote acceptance (though I don't guarantee it.)

1. Understand how end-users work: Find out why they do the things they do. If you show an interest in them, they will be more comfortable with what you're trying to accomplish.
2. Provide opportunities for feedback: This is particularly important when there are user interfaces involved. At regular intervals, let people see the development and direction and be willing to listen to suggestions and feedback.
   
3. Manage change: If something has to change let your customer understand the rationale. "Because it has too..." is not a useful response. If the change is meant to make things better explain how.
   
4. Make it seem familiar: People by nature are resistant to change. Perhaps there is opportunity to gradually phase in changes (smaller changes are easier to digest) or provide an interface that is similar to an existing one.
   
5. Enlist champions: End-users that can teach other end-users are a great way to provide support. It also gives the champions a sense of ownership for the adoption. Early adopters are good individuals to use as champions.
   
6. Teach don't point: When someone asks for help one of the worst things you can do is point them to a manual. Spend time to teach them how it works. Show them they're important.
   
7. Measure & report: If the new solution is meant to improve productivity, show them the gains that have been made over time as the end-users become more familiar and move up the adoption curve. This type of information shouldn't just be provided to the project sponsors and management.
   

Projects are usually justified quantitatively based on achieving benefit targets (e.g., gains in efficiency or increases in sales.) Maximum benefits will not be achieved if the end-users do not embrace the solution wholeheartedly.

Knowing when it's good enough

A business uses cost-benefit analysis as one of its evaluation criteria when deciding whether to pursue an opportunity or not. One concept central to this is the assessment of potential risks. To me there are a few components to risk assessment:

1. Likelihood of the risk materializing. What's the probability of the risk becoming a problem?
2. Potential cost (monetary, compliance or reputation) to mitigate the risk. How much is it going to cost you? This also includes implementing any mitigation strategies.
   

Combined, these factors provide a value to each risk. Risk assessment can be applied in many different areas:

• Managing the risks encountered in a project.
• Understanding the importance of a defect or bug in a system.
• Managing financial assets.
  

For the purposes of this post I'm only going to write about the second item.

What do you do if you find a defect or bug in a system? You evaluate it to determine whether it's a show stopper or whether you can proceed despite it. Creating bug-free software is the ultimate goal but it has cost and time implications. Here's a quote from an article, They Write The Right Stuff, from Fast Company about a specific software system.

This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.

The piece of software in question runs the NASA space shuttle. The consequences of failure could result in the deaths of the astronauts, the loss of a multi-billion dollar piece of hardware and many years of setbacks to the space program. Many of the systems we deal with in the business world do not have this level of criticality. In my past jobs I have worked with time sensitive trading systems where 1/2 second delays mean losses in the $10,000's of dollars. On other projects, variances in marketing and market research data were explainable ("Yes, someone did purchase 50 rolls of toilet paper and it skewed the numbers.") We need to understand when something is good enough as it is instead of always trying to be perfect.

Agile Project Leadership Article

There's an interesting article on ProjectConnections.com called Agile Project Leadership. In it the author, Kent McDonald compares and contrasts traditional project management characteristics versus agile project management ones.

To summarize the article, the basic differences were:

• Task versus feature driven.
• Process and control versus anticipate and adapt.
• Fully detailed versus iterative project plan.
• Leadership versus team driven.
  

To this set of differences I would like to add something from one of my previous posts, System Development Life Cycles & Requirements,

• Process versus people-oriented.

If project management characteristics change depending on the nature of the approach taken, what about the approach to requirements? What differences would one expect to see? What concepts are important?

Stop 'gathering' IT requirements

There's a post on Techrepublic titled, Project Managers: Stop "gathering" IT requirements.' It's an interesting read.

And when I ask why projects get bad requirements, the answers are, "Users won't tell us what they want," or "We don't ask good questions," or "What they told us they wanted turned out not to be what they really wanted." But I think that the problem is more subtle than any of those answers.

The author, Paul Glen's, point is that, "project managers should negotiate requirements among the stakeholders." My comments on the article are as follows:

• In order to negotiate well, a project manager really has to understand the nature of the project and client ask. If the project manager doesn't understand the ask (e.g., isn't familiar with the business), a strong supporting cast is needed to keep everything real. Are you more confident when you know your project manager has lead projects similar to the one you are on or is very familiar with the industry?
  
• Requirement 'gathering' means collecting requirements, however, a business analyst is paid to understand them, derive meaning from them and then communicate the underlying business objectives. To me, this is the core competency of the role. The article does not really talk about this. You do not need a business analyst to order take.
  
• The following comment from the article seems a bit over the top, "We should think of a set of requirements as being like a multilateral treaty among a group of nations." I understand the need to have clear understanding and expectations, but this sounds like something people do when they don't trust each other.
  

I think, if anything, this accentuates the need to have a strong capable business analyst.

It's a bigger world

We've all encountered situations where difficult decisions had to be made concerning a project.

• Should we continue?
• What features do we need to pare back?
• Do we need more money?
• Are we missing needed skill sets?
  

These decisions are normal things that occur within any project. However, the ramifications for handling them may impact things outside of the project in question. What if an increased budget means another initiative has to go unfunded? Or perhaps the added resources need to be taken from another project's resource pool?

Instead of managing a specific project, decisions have implications across a collection of inter-dependent projects. The management of the collection is termed program management. The purpose of program management is to use the scarce resources and funds available to orchestrate projects to deliver maximum benefit. If you've taken basic economic theory you may remember the definition of scarcity.

The basic economic problem which arises from people having unlimited wants while there are and always will be limited resources. Because of scarcity, various economic decisions must be made to allocate resources efficiently.(Investopedia.com)

It's true, you just can't do everything!

One thing I was told very early about projects is that, "Projects end. If it doesn't, then it's not a project." If that's true, then programs, being a collection of projects, end as well.

But we also know that businesses constantly evolve. Their products and services are impacted by innovation and change caused by internal or external sources. If you will, the portfolio of service offerings evolves continuously. To me, I view this evolution as portfolio management. Clearly, this terminology evolved from finance however, it is also applicable to the management of a company's set of offerings and how they are transformed over the passage of time.

The art and science of making decisions about investment mix and policy, matching investments to objectives, asset allocation for individuals and institutions, and balancing risk vs. performance.

Expanding further upon the concept of program-wide decision-making is the notion that decisions across a portfolio can have implications in many of the different programs within it. A portfolio is governed by the higher level strategic goals of a company whereas program decisions are governed by lower level objectives.

For example, suppose one of your strategies is to become a low-cost provider for a given product. Your product development team may look at projects that reduce the cost of the materials used while your service team may reduce the number of agents who handle customer inquiries and beef up the self-help sections of your website. Together, these two programs work towards meeting your strategy.