Monthly Archives: October 2006

Business Rules And Requirements

No parking sign

What is the difference between a business rule and a business requirement? Does the difference matter? A business requirement is something that is multi-customer, and a business rule represents a single customer’s approach to meeting that requirement. Product managers and analysts care about both, but product managers emphasize requirements, and analysts focus more on rules.

A Simple Example

We’ll set the stage for discussion by showing a requirement, a rule, and a design and implementation.

  • Requirement – The building will provide a measure of protection against fire damage.
  • Rule – Firefighters will be assured access to the building to enable extinguishing of any fires.
  • Design – The street near the fire hydrant and main entry of the building will be reserved for exclusive use of firefighters.
  • Implementation – A sign will be posted in a visible location, instructing people not to park in the reserved location.

Background

The debate about requirements versus design, and the level of detail of specification has been an active one over the past year. We’ve written about how you can imagine software as an onion, where implementation is wrapped in design, which is wrapped in requirements. When we include awareness of business processes as part of what we’re doing, we can add another layer – business rules.

One point of confusion may be that many contracts are described as “gather requirements” when in reality, the work is “define rules appropriate to a set of predefined requirements.” This inconsistency leads to many debates that include arguments like “that isn’t a requirement, therefore it must be design” with the response of “that isn’t design.”

Ideation

Moving from each layer to the next involves ideation, and exhibits concreteness. For a given requirement, an approach can be defined for meeting that goal, and with that approach comes rules. For each rule, a design can be selected, and for each design, an implementation is created.

Each step involves ideation – making inventive choices about how to achieve that next step. Consider our example. We have the requirement of providing protection against fire damage. We could choose to achieve this requirement by mandating that only non-flammable materials be used in the construction of the building, or by integrating fire suppression equipment in the building, or by optimizing the access for firefighters to the building. Once we make that choice – an ideation step – we define the rules that express how we will achieve our goal with the selected approach. Our rule is assured access in this example. The design approach is to reserve the street near the main entry to the building. The implementation of this “reservation” is a sign. It could be special barricades that block access to anyone who isn’t a firefighter.

The point is that there are choices at each step of the way.

Each step becomes more concrete, more focused, and more narrowly applicable.

Product Managers Are Market-Centric

As a product manager, when interacting with customers to better define the needs of the market, we need to recognize that the rules are not the requirements. In the example, access for firefighters isn’t the requirement, protection against fire damage is the requirement. This is the level of abstraction that can be used to describe market needs.

Business Analysts Are Customer-Centric

A business analyst needs to understand the requirement (protection), but only in so much as it affects her company. This allows her to explore alternative rules (access, suppression, prevention, etc.) that will achieve the requirement.

Requirements Elicitation Can Fall Short
When we interview people to gather requirements, they will usually talk about implementation, design, and rules. Rarely will they describe requirements. Users and subject matter experts (SMEs) generally talk about implementation and design (“We have a sign, because the street needs to be reserved.”). Our elicitation techniques and listening methods help us identify rules by asking Why? (“To assure access to the building for the firefighters.”). Without those techniques, we will only uncover implementation and design.

Getting to Requirements From Rules

To get to the requirements, we need to keep asking why. (“To provide protection against fire damage.”) If we keep asking “Why?” we will eventually get to a useless “primary goal.” And by useless, we mean that it is a goal that is too nebulous to drive anything actionable. Consider these possible chains of why questions and answers for our example:

  • Why provide protection against fire damage? To allow us to meet city codes. Why does that matter? So that we can legally rent out space in the building. Why does that matter? Because we need to rent the space to make a profit. Why does that matter? Because our shareholders demand it.
  • Why provide protection against fire damage? To allow us to charge higher rent to tenants. Why does that matter? Because we need to maximize our profits. Why? Shareholders.

Part of the art of product management is knowing when to stop. “Protection” is actionable. “Satisfying shareholders” and “Profit”, while laudable goals, do not provide the needed direction and detail to be actionable.

Summary

The line between requirements and design is broad, and is more of a region than a line. Rules live in that region – from one perspective they embody a design approach to achieving a requirement. From the other perspective, they represent the business requirement, in more detail. Use elicitation techniques and ask why to uncover the rules and requirements.

How Many People for Requirements Elicitation?

requirements gathering session

How many people should be involved in requirements elicitation? A question from one of our readers via email.

Hi Scott, in the last months I faced the issue of managing the requirement elicitation phase in an Identity Management project. I have a very simple question. In your opinion how many people should do the interview process against the customer ?

In my experience one person is not enough even if the interview session is electronically recoded. I have observed the two heads are much more better than one since two different points of view are captured from the Voice of the Customer.

I’d be happy to hear your opinion on this.

Thanks for the great question! I’ll turn this into two questions and try and answer them both.

  1. How many requirements gatherers should gather requirements from the subject matter expert (SME)?
  2. How many SMEs should be providing requirements to the requirements gatherer?

How Many Requirements Gatherers?

A simple question deserves a simple answer: two if you can afford it, one if you can’t. Feel free to skip the rest of the article. :)

The success of requirements elicitation hinges on our ability to listen effectively. Active listening allows one analyst to get the same information from an answer that two people (who hear things differently) would get. The bigger benefit of adding a second person comes from asking questions. Two people will identify more loopholes and corner cases, will ask questions that uncover unspoken requirements, and otherwise improve the quality of the information gathered. Will they identify twice as much? No. There’s a law of diminishing returns at play. And the greater the skill of the analysts, the more overlap there will be in the questions they each ask. A third analyst won’t add much at all, and will run the risk of getting distracted and not really contributing anyway.

Having two interviews, each by one analyst, each of a single SME, will probably unearth more requirements than if both analysts interviewed a single SME once in a joint session. When the schedule/budget is tight, use this approach for the most efficient requirements gathering. When efficiency is not a driver, then doubling up the analysts will get better data – just not twice as good.

How Many SMEs?

Another valid question is how many SMEs to interview in a single session? I think two is an ideal number. One SME will unconciously gloss over details, that a second SME will catch. The two SMEs can debate contentious points, and correct and help each other. If both SMEs aren’t available for the same meeting, meet with them sequentially. Have the second SME review the requirements that were documented with the first SME.

Again, there is an efficiency issue – do we double up the SMEs (and the cost of them), or do we work with them sequentially? Doubling up is better, but again, not twice as good due to diminishing returns. A third SME is likely to cause the conversations to devolve and become much less effective – even if uncovering more details, the overall process will be less efficient.

Other Factors

There are a couple other factors that have more of an impact than perfectly optimizing the number of attendees. The best way to improve requirements gathering is by increasing the experience/skill of the business analyst. Check out the factors at the end of this article on estimating requirements gathering for more details. Similarly, SME aptitude plays a role.

As analysts, we have to be able to wear a bunch of different hats. We are talking to SMEs about their expert domain. We are validating that our requirements are attainable, by applying our knowledge of the IT world. And we are making sure that we focus on the most valuable requirements by applying some understanding of ROI. Basically, we have to be comfortable operating in all three domains of expertise.

Intimate Domains

If we find that we need to include more people in our meetings to get coverage across all the domains, that would supercede the “two is better than one, but one is more efficient” arguments from above.

Conclusion

We have to make sure we get coverage of each domain of expertise. One person is more cost-effective than two. Two people will elicit better requirements than one.

Nice To Have

boy with cell phone

Gathering requirements isn’t like asking kids what they want for their birthday. We aren’t giving our customers carte blanche, we are trying to identify the valuable requirements – things that solve problems and achieve value in a significant way.

Needs and Wants

Our customers usually know what they want. There’s a debate about if customers know what they need. Kids want cell phones. But how many kids need a cell phone? Assuming they aren’t working Canal Street in New York City to warn counterfeiters about police raids, they probably don’t need them.

We presented a hierarchy of customer needs, stealing from Maslow for inspiration.

  1. Meets the needs of our business
  2. Fulfills the wants of our business
  3. Enables us to improve the way we do business

The first level in the hierarchy is definitely a “must have” requirement. The second level might be a “must have” or might be a “nice to have”. The third level is most likely a “nice to have”, but could be a “must have” requirement. To tell them apart, we need to understand, scale, ROI, and context.

Scale

The scale of a requirement is measured in terms of benefit to the business of implementing the requirement, or impact to the business of not implementing it. We talk about positive benefits, but sometimes it is easier to start by measuring the impact of not having a requirement implemented.

For example, it is easy to imagine the impact of an exterminator running out of pesticides while he is on a route – perhaps the lost time to replenish his supplies. From an impact standpoint, this might be 2 hours lost (and therefore two treatments rescheduled). To determine the benefit of sending out the exterminator with sufficient chemicals, we can multiply the impact (say $150 in lost revenue, assuming an otherwise full treatment schedule) by its frequency – once every 5 weeks per exterminator, to get a $1500 potential for annual savings. Multiply this by ten exterminators, and we are talking about a $15,000 per year scale.

This might be large enough to be high-priority, or it might not. We don’t know.

ROI

To measure the ROI of a requirement, we have to understand cost as well as benefit. To assess cost, we have to move out of the requirements realm and into design. From that design we can estimate the cost of the solution.
We could solve the exterminator problem with some fancy data models that predict usage based upon historical data and an analysis of the scheduled treatments of the day. This would involve the costs of collecting, analyzing, and maintaining the data, as well as the cost of calculating the quantities every day.

We could also attempt to solve the problem by having all exterminators carry an extra 10% more pesticides. If the pesticides for a given treatment cost $10, and a typical schedule includes ten treatments per day, we would increase the amount of work in progress (WIP) inventory by 10% or $10. An old manufacturing rule of thumb says that the cost of maintaining inventory is on the order of one third of the value of the inventory on an annual basis. Using that estimate, the cost of increasing inventory levels is about $3 per exterminator.

Potentially, we are saving $15,000 for an investment of $30. That is an ROI of 5000%!

This certainly would exceed the hurdle rate for our expected value calculations – but we still don’t know if this requirement has a high priority.

Context

We could be in the middle of a project that saves our customer a million dollars. A potential savings of $15,000 is not going to be worth considering in that context. However, if we are in the middle of a project that asks us to save as much as we can with a $500 maximum investment, the requirement seems very likely to be high in the priority list.

Conclusion

We have to understand how much a solution to a problem might save our customer. We have to know how much that solution will cost – to determine ROI. We also need to understand if this problem is the elephant in the room, or a fly on the elephant. If the relative financial impact of a requirement is low, it should not be prioritized above a requirement with more “bang for the buck.”

Run A Meeting Like Google

google

Some outside reading…

BusinessWeek just ran an article on how to run meetings like Marissa Mayer, VP of search products at Google.

She has six main ideas:

  1. Set a Firm Agenda
  2. Assign a Note Taker
  3. Carve Out Micro-Meetings
  4. Hold Office Hours
  5. Discourage Politics, Use Data
  6. Stick To The Clock

Take a couple minutes to read it, then take a look at our earlier article on making meetings 60% more effective.

Our Thoughts

Marissa provides advice that falls in one of two buckets – tactical and strategic.  Tactically, she suggests we manage our agendas and schedules (1,2,6).  Strategically, she proposes that we get creative with the schedule, and focus on the topics at hand.  Office hours is an interesting idea – relieving the pressure to find the time for initial conversations and quick meetings (approvals, etc).  Micro-meetings help with efficient use of other people’s time.

Wants and Needs

Mr potato head

When a client asks for a capability or feature – is it a want or a need? How do we prioritize them?

Maslow’s Hierarchy

Abraham Maslow proposed in 1943 that humans are psychologically driven to meet a set of needs, or achieve a set of goals that range from “basic” needs to “higher” needs. His theory is that people focus on the most basic needs, until they are achieved, then advance to the next level of needs, defining a hierarchy of needs. We have a saying at home – “If that’s the most important thing you have to worry about today, things must be going pretty well!”

Maslow’s hierarchy defines needs in the following set of increasingly “higher” categories:

  1. Physiological / biological needs
  2. Safety
  3. Love / belonging
  4. Status / esteem
  5. Actualization

The logic is straightforward – until a person addresses his hunger, he doesn’t care about job security. Until he has job-security, he doesn’t care about recognition for his efforts. Each base need must be met before someone prioritizes the next level in the hierarchy.

In other words, until we have enough potatoes, we don’t care if we have enough mr. potato heads.

Customer Requirements

Many customers exhibit a similar behavior. When thinking about software purchases, or feature prioritization, they may have a hierarchy that looks like the following:

  1. Meets the needs of our business
  2. Fulfills the wants of our business
  3. Enables us to improve the way we do business

If the software doesn’t do what it must do, then we don’t care if does extra stuff. Only when the software helps me deal with today (both needs and wants) do I care about how it helps me reinvent for tomorrow. The tactical takes precedence over the strategic.

balancing rocks

Balancing Act

We have to perform a balancing act – climbing as high up the hierarchy, without going too high.

Climbing the Hierarchy

Determining how to address this hierarchy with our products / solutions can be tough.

  1. We have to address all of the needs, or our product will be eliminated from consideration.
  2. We have to address at least some of the wants or our product won’t be differentiated in the market.
  3. When we can innovate and help our customers innovate, we have a great opportunity.

The trick is to remember that we have to address the basic needs in the hierarchy first. Our software must address the needs – that is the price of admission. By addressing the wants of our clients, we can differentiate ourselves. All viable (by definition) competitors must be addressing the needs already. And only when we have satisfied wants and needs can we ask our customers to become introspective and consider reinvention of their business in a way that redefines wants and needs, in order to achieve a discontinuous improvement.

Here’s a soundbite version of the same hierarchy:

  1. Required
  2. Desired
  3. Inspired

Going Too High

When we try and do too much, we can alienate our potential customer and lose the deal. Or worse, we can close the deal and lose the users. Featuritis is the all-to-common condition of having too many features in our software, trying to tackle all of the wants and needs. The extra features make it too hard to learn how to use our software, alienating users. Without adoption, we won’t achieve the value promised by our software.

Anecdote

A situation that happened today, when defining a future business process:

  1. We defined the steps involved in modifying some business objects.
  2. We agreed that this was required to support a previously scoped business process.
  3. The business owners asked for the ability to see the results of the modifications.

The first step was validated in the second step as one of our needs. The third step looks like a want. The “ability to see” was a manual “let me just make sure that it worked” step. When we asked the question “Which business process requires you to see the results of the modification?” the answer was “None.” It turns out that a manual inspection only provides confidence to the user that things are working as they should.

Potato? Or potato head?

Our vote is potato head, as their is no ROI gained or lost by including or excluding this feature. Emotionally, that was hard for our business owner to accept (and no, we didn’t use the potato head analogy). Ultimately, we will include this feature, but only with the awareness that it is lower in priority than required features.

The implementation of the feature happens to be essentially free, and the goodwill and initial user adoption benefits are enough to make the value measurable, however transient it is. Therefore, our “in the real world” decision was to include it. In the theoretical world, we would have excluded it.
Conclusion

Customers care first about things that are required, and then about things that are desired. Only after addressing those two can we propose solutions that are inspired. Thanks Maslow!

Goal Driven Upgrades

upgraded seat

Kathy Sierra writes (another) great article at Creating Passionate Users. This time, she talks about why users don’t upgrade and presents ways to get users to install the latest version. We focus in this article on one way in particular – using goal-driven documentation to encourage upgrading.

Background On Documentation

Over the last couple of days, we’ve written about how to structure documentation to define what users can do with the software, instead of capturing what the software can do for users. This reverse approach uses user goals to guide our documentation. We also presented, more concretely, how to trace and manage our goal-driven documentation with use cases.

We can leverage this documentation approach to achieve two additional benefits:

  • Encourage users to install new upgrades
  • Encourage users to migrate from other applications to ours

The same factor is at play in both situations – users already know how to use their existing software, either a previous version of our software or a competitors software. The fundamental question for users is “How will I do what I need to do?” This is a major barrier to both upgrades and migration from other applications.

Kathy On Upgrades

Kathy’s article on why users don’t upgrade is awesome. She creates a great visual graph (shared via her CC license) of the user’s perspective on upgrades:

Sierra's Graph

Why they don’t upgrade (and what to do about it)

Kathy goes on to list several approaches to address the problem, all of them fall into either “make them want it” or “make it easier.” We will focus specifically on how writing goal-driven documentation can help.

Make Them Want It

We must apply the same prioritization approach to defining upgrades as we do to defining the initial release. This assures that the most valuable not-yet-implemented goals are addressed in the new version of the software. If we are using Kano as a framework for prioritization, we have the added benefit of effectively lowering the suck-threshold.

Make It Easier

We can make design decisions that make software easier to use. We can also follow Kathy’s other good suggestions. And we can write our documentation to make it easier for users to make the change.

Goal-driven documentation has two effects on the curve Kathy drew above. Here’s the same curve, representing a typical software upgrade:

typical upgrade

With goal-driven documentation, the curve is shifted up and to the left:

shifting the curve

This shift can be analyzed as two different factors:

two factors

The goal-driven documentation allows users to climb become more competent more quickly – effectively lowering the suck-threshold. When applied to upgrades, it reduces the size of the drop – preventing users from re-entering the suck-zone.

Faster Climb

Competence is not a measure of how quickly users can do everything the software can do – it is a measure of how quickly users can do everything they need to do with the software. When we define our software to prioritize solving the most valuable problems for our customers, we are defining the set of activities that the users need to do. And we identify this as a set of use cases.

We then document how users will follow those use cases, with the implementation we’ve given them.

structured doc

This goal-driven approach to documentation helps users climb the competence curve much faster, immediately reaching the “Finally I can actually DO something” point (above the suck threshold). As long as we document the right somethings, we’re all set.

Shorter Drop

We apply this same approach to our upgrades. Those use cases that we’ve added in a new release yield new documentation. Those implementation areas we’ve modified as part of the upgrade yield updates to previously released docs.

Users will have an easy answer for “how do I do it now?” as well as “What can I do now?

Collateral Benefit

We also get the benefit of making it much easier for users to migrate from other software packages (not just our earlier releases). There are books out there where authors address exactly this problem – Microsoft Word for Wordperfect Users and Java For Cobol Programmers come to mind. By showing users how to do what they need to do, we make it easy for them to switch.

Conclusion

  • Goal driven documentation makes it easier for users to learn how to use our software.
  • Goal driven documentation makes it easier for users to switch from other software programs to ours.
  • Goal driven documentation makes it easier for users to upgrade to new versions of our software.

Use Case Driven Documentation

drilling

Yesterday we wrote about focusing our documentation on what our users are trying to accomplish. With a structured requirements approach, or with an interaction-design driven approach, we’ve already solved half the problem – determining what to document.

Our proposed documentation approach is to write about what users are doing with the software, not what the software can do for the users. Using a power drill as an example, we proposed the following representative approach:

  1. How to drill a hole in a flat surface (wood or plastic, metal, masonry).
  2. How to select the right screw for fastening items.
  3. How to drive screws (phillips, flat-head) with your drill.
  4. How to stir paint with your drill.
  5. etc…

Suddenly, the documentation is helping us to achieve our goals.

Extending Structured Requirements

When we use a structured requirements approach, we have established a framework for defining the problems that our software will solve. We articulate how people solve those problems with use cases. These use cases define exactly what we need to document.

When we view structured requirements, they look like the following diagram:

structured requirements

From Non-Functional Requirements Equal Rights Amendment

We extend this structure by leveraging the fact that the use cases identify the highest priority tasks that users will perform to achieve goals. These are therefore the highest priority tasks to document. The documentation represents how a user would achieve a use case, with the implementation that we’ve created.

structured documentation

We can even trace each portion of our documentation work to the use case that it supports.

Extending Interaction Design

With interaction design, we are again focusing on what people intend to achieve while using our software. Even if we are writing game software (which is designed to be played without a “goal” in the traditional sense), the user still has a goal of “being entertained.”

With interaction design, we would write documentation that demonstrates the way that scenarios play out with the given implementation that we created.

Even when combining interaction design and structured requirements into a hybrid approach, we still have a source from which to define our documentation needs – the scenario.

Summary

We’ve previously defined the benefits of documenting what users do with our software instead of documenting what our software can do for users. In this article we present a framework for defining and tracing that documentation – building upon use cases or scenarios. This documentation approach makes for software that is easier to use, and therefore better.

Goal-Driven Documentation

power drill

Why do we write documentation? Because someone told us to write it? Because our competitors have it? Or because we want our software to be easier to use? It should be the third one, but often, writing documentation is an afterthought, and it is deprioritized, and we just get it done, instead of thinking about the goals for doing it in the first place and doing it right.

Instructions for a Drill

Imagine that the instructions for your brand new electric drill had the following sections:

  1. How to adjust the speed of your drill.
  2. How to change the direction of the drill.
  3. How to change the drill bit.
  4. etc…

You wouldn’t know very much about how to accomplish something with the drill – you would only know how to operate the drill. What if the instructions had the following sections:

  1. How to drill a hole in a flat surface (wood or plastic, metal, masonry).
  2. How to select the right screw for fastening items.
  3. How to drive screws (phillips, flat-head) with your drill.
  4. How to stir paint with your drill.
  5. etc…

Suddenly, the documentation is helping us to achieve our goals.

Do The Job (Versus Use The Tool)

We write documentation so that people can more easily do the job, not so that they can use the tool. In our example above, the “use the tool” instructions in the first list would be fine for someone who already knows how to use a drill – it would only teach them the unique elements of how to use this drill.

Software doesn’t present the same set of physical affordances that hardware does. Rarely are there a handful of obvious physical controls begging for interaction – “That looks like a trigger, and the drill looks like a gun – I bet that’s how I make it spin!”. Instead, we have a myriad of choices – buttons, menus, hidden context menus, command line prompts, gestures, etc.

With rare exceptions, we aren’t writing documentation to teach someone how to use our software (instead of some other software they already know, which does exactly the same things). We are trying to teach them how to achieve their goals and solve their problems, using our software.

We defined requirements to solve problems and achieve goals and generate value. Shouldn’t our documentation be written with these same goals in mind?

Creating Competent Users

cannister vaccuum

We’ve written before about Kathy Sierra’s now famous suck threshold. The suck threshold is the minimum level of competence required for a user to feel like they don’t suck when using the software. We talked about it in the context of defining the right number of features to include in the software. More features means more complexity which means users take longer to master the software.

suck threshold

We’ve also talked about how to prioritize features for software to maximize the likelihood that our users will operate above the suck threshold. We have to prioritize for competent users (people above the suck threshold) because beginners aren’t beginners for long, and few people invest the time and effort to become experts.

A key articulation users propose for why software sucks is that they can’t understand how to achieve their goals.

Our Documentation Should Help Users Achieve Their Goals

Pretty simple, really. Many software “manuals” have documentation that is organized to mirror the user interface – a section for each menu, with a sub-section explaining how to use each item in the menu (“How to adjust the speed of the drill”). It is left as an exercise for the user to know when, why, and how much to adjust the speed of the drill. These gaping voids provide a great market for authors – how many trees have died to publish “How to use Access” and “Secrets of Word” and “Excel for Dummies?”

Thankfully, there are good examples of documentation out there. Subversion, open source source-control software, has goal-driven documentation. It serves as a great example, in that the documentation (an open-source book, really) shows how to use subversion to achieve particular goals (how to migrate from another solution, how to restore my old file, etc), or how to set up subversion to operate in particular situations.

Goal-driven documentation effectively lowers the suck-threshold. It allows us to include more features (because we can more easily ignore them, and because we can see how and why we might use them, instead of just understanding how they operate). Goal-driven documentation also accelerates the user up the learning curve, allowing them to be productive far more rapidly.

Summary

Write goal-driven documentation. It helps users achieve their goals using the software. This creates more competent users more quickly. And it helps generate evangilists and salespeople within the user community.

Follow the Product Leader

Follow the Leader

Follow the Product Manager Leader

We all remember how to do it – both following and leading. Product Managers do not have corresponding authority for all of their areas of responsibility. We have to manage somehow, and what better way than follow the leader?

Outside Reading

Paul, at Product Beautiful, a new blog about high tech product management, has a good article about product manager burnout. Paul uses the circumstances of school psychologists to show that when responsibility does not come with commensurate authority, it leads to burnout. He extends this idea to product management.

We have lots of responsibility with varrying degrees of authority. In almost all cases, PMs don’t have direct management authority over the people who are essential to creating the software, service, or product. For this reason, a PM must develop awesome communications and negotiation skills to be successful and avoid burnout.

Burnout in Product Management

Pragmatic Marketing runs an annual survey to understand, among other things, the reporting structure for product managers in their companies, and what responsibilities the respondents identify. Top in the list of responsibilities for product managers are:

  1. Writing Product Requirements
  2. Monitoring Development Projects
  3. Researching Market Needs
  4. Creating Sales Presentations and Demos

Most product managers have authority at least around researching needs and documenting requirements. Few if any have authority to manage development teams – which is Paul’s point.

Management Style

Paul offers that there are many ways to manage the team – from Command and Control to Follow the Leader. He prefers, and we strongly reccommend follow-the-leader approaches.

Follow-the-leader takes more than communication, it demands inspiration. Different people are inspired by different things. We can inspire people who want to do something important with a vision of the product from a high level – what problems will it solve, how valuable is it, how will the person contribute? We can inspire people who are focused on their own goals – how will this role help them learn and grow, achieve visibility, become more marketable? Each person has a different mechanism. And it is up to us, as leaders, to figure out exactly how to inspire them.

21 Dysfunctional Definitions

Dictionary

Dysfunctional Definitions

  1. Agile– Approach that jumps through hoops to avoid providing a project forecast.
  2. Broken Windows– What over-worked developers create when driving through the code-base late at night.
  3. Business Analyst– Person who sweeps problems back out from under the rug for their customer.
  4. Deliverable– A measurable output of work, completed after the scheduled date.
  5. Developer– Person who creates solutions to unidentified problems.
  6. Innovation– What happens when managers fail to do their jobs correctly.
  7. Intellectual Property– Secret Sauce. Used to achieve the impossible. Alternately, used to prevent other companies from achieving the valuable.
  8. Iron Triangle– The rationalizing tool for reducing quality to meet the schedule.
  9. Meeting– An opportunity to stop all useful work and take a break. Effectiveness is proportional to the number of attendees.
  10. Offshoring– Going to the ends of the earth to help the developers, then finding their replacements there. (IP “borrowed” from Dispair, Inc)
  11. Product Manager– Person who identifies problems that apply to all customers except yours.
  12. Quality– The feng shui of software.
  13. Review– A meeting where all previous work is discarded and new work is defined. Followed invariably by another review.
  14. Rework– Replacing broken windows (see Broken Windows)
  15. Risk– A means by which reality is infused into projects.
  16. Schedule– A perfect prediction of the future and all project events. Schedules never change.
  17. Scope Creep– Theoretical event that my friend’s brother’s cousin’s neighbor once heard about happening on a big project.
  18. Software Salesman– Person who reserves weekday tee-times for CIOs and purchasing managers.
  19. Status Report– A transmogrification of reality to conform to the schedule (see Schedule).
  20. Timebox- A five gallon hat, into which ten gallons of work must be stuffed.
  21. Waterfall– Approach that maximizes the ability to plan to fail to deliver the right software.

More

Add to the list or provide alternate definitions in the comments below!