PM Blog: Kent McDonald

Running the Numbers

2008-06-25T14:41:00-07:00

by Kent McDonald

When I am not writing articles or working on projects, I spend my spare time doing volunteer work with a couple nonprofit groups. Through twists of luck, fate, or odd coincidence, I find myself either helping to organize events or providing advice to others who are organizing events—be they charity fundraisers or industry-focused conferences. Through working with all of these events, I have found that having a model of the finances for the conference helps me to make decisions that ensure the conference delivers the optimal value. I have also discovered that this tool can be applied to projects of all types.

Lately I have been advising two different groups made up of well intentioned but inexperienced people organizing mini conferences. They eagerly leapt into planning their events thinking all they needed to do was pick a hotel, get some compelling speakers, post some announcements, and wait for the attendees to sign up. Unfortunately, it's not that easy. There are numerous costs that someone unfamiliar with event planning wouldn't consider. There are a lot of decisions to be made that tend to be interconnected and require several different pieces of information that quickly become overwhelming to keep in one person's head. They needed a tool to help them keep all the information straight in order to make informed decisions based on impact to the value generated by the conference, much in the same way that project teams need to make decisions about their project.

To help these groups out, I created a rather sophisticated, yet elegantly simple (in my biased opinion) conference financial model to use when planning conferences. I call it a financial model because it does not stay static across the life of the activity like a traditional budget. Instead, it allows me to change various inputs and test certain assumptions and immediately see the expected impact on the money made or lost by the conference. This mindset of change and adaptation can be applied to leading projects as well.

How To Use a Financial Model To Your Advantage

Consider Income

When people hear "project budget," they immediately think about a single number or range of numbers that indicates how much money the team can spend on a project. This reinforces the perception of the project as a cost sink and leads project teams to ignore potential income derived from the project, whether from increased revenue, protection of existing revenue, or cost savings. If you account for the income generated by the project, you are putting yourself in a better position to evaluate the full impact of the project on the organization. This income may be difficult to estimate initially, but if you follow the next piece of advice, you can always revise the model as new information becomes available.

Use Change to Your Advantage

Most project budgets are static, or are at least built to be very difficult to change. This limits the team's ability to quickly test out different scenarios based on different cost or revenue projections, which limits the information available for their decision-making. Knowing your options can be helpful, but not very enlightening if you can't easily see the result of those options on the overall project. I built my financial model in a spreadsheet so I can easily change key input data (additional food and beverage items, detailed audio/visual line items, number of sponsorships, and number of registrants, for example) and quickly see the resulting revenue or loss from the event. Building a similar financial model for your project allows you to revise costs and expected revenues to quickly get an up-to-date picture of how successful (or not) your project will be in terms of value delivery.

Know Your Assumptions

Once you have a model in which you can change various inputs, identify which of those inputs are assumptions. In this case, any number that you do not know with 100% uncertainty is an assumption. Make sure that you can change the assumed number and see the impact of that change on all related parts of the model. For example, in my conference financial model, the number of attendees is an assumption. It has an impact not only on revenue (from registration costs) but also on costs (primarily food and beverage). We won't know the actual attendees until the day of the event, but the model is set up in such a way that we can revise our expected numbers throughout the signup period as more information becomes available.

Another example of an assumption is A/V costs. When starting work on a conference, I put a rough estimate of A/V costs into the model as a placeholder. This assumption is based on previous conferences, and accounts for some costs until I can get a firm idea of costs from the event location. Once I get that information, I can replace the assumption with the actual value, and make sure that the A/V equipment listed is sufficient.

Use the Model to Play "What If"

One of the advantages of a dynamic model is the ability to try different inputs and immediately see the result, which provides information and helps you to make decisions about what actions to take next. For example, the number of attendees is a key number because of its impact on income and costs. Whenever I receive new, concrete information, I update the model and revise the number of attendees to determine a new breakeven point. Changing the number of attendees and watching for the point where the conference gross revenue results in a positive number tells me the minimum number of attendees the conference needs to avoid losing money based on the current costs. The resulting number then leads me to decide whether additional marketing is needed for the conference.

Use the Model as a To Do List

Creating a financial model helps you to approach a project from a different perspective. Instead of trying to think of everything you have to do, think of what costs you could incur on the project. These items may lead to additional tasks or features you might not have identified through other means.

Although every project is different, you can still use a financial model from a previous, similar project as a starting point. The line items included in this financial model template often remind me of things I originally had not thought of when putting the task list together. The basic rule is, if you spend money for something, chances are you have to do something to spend that money.

Take the Emotions Out of Decision-Making

Financial models are an excellent way to spell out all the facts in a way that is hard to dispute. They highlight the true feasibility of a cost structure in plain black and white (or red, in some cases). As I have helped these two groups plan these upcoming conferences, I often ran into cases where they did not believe my advice about how imbalanced the registration fee and cost structures were. They were falling into a normal reaction for anyone involved deeply in an effort. They lost sight of the big picture. I set up the financial model and gave them some suggestions on how to use it, and then let them go at it, figuring they were tired of me telling them they could run into problems. As they began filling in various inputs they began to see several places where cost and revenue were out of balance. The good thing was that the facts plainly stated that some actions needed to be taken to get the financial picture in order, and they were able to try different things to determine the best actions to take.

Leave Your Options Open

If you establish a financial model early and update it as new information comes available, you are giving yourself a powerful tool for making informed decisions and commitments on your project. What's the difference between a decision and commitment in this context? A decision is when you determine a particular course of action that you are going to take, or choose to defer taking any action. A commitment is when you actually take a course of action and will incur consequences if you reverse or substantially change that course of action. Commitments occur either by communicating your decision to a wide audience, thereby establishing expectations, or by actually spending money. Decisions are very easy to revisit. Commitments are more difficult to revise. You want to defer your commitment until it absolutely has to be made in order to avoid a loss in value.

In our conference planning example, we commonly run into a couple of commitments. The first one is usually signing the contract with the facility. Most conference facilities and hotels use standard event-hosting contracts that include various cancellation penalties. Once you sign the contract, you are on the hook. Put another way, you have made a commitment, the value of which is that cancellation penalty. There is a natural tendency to rush to sign the contract to lock up the space, and hotels tend to encourage this behavior. There is almost always time to do some analysis before making that commitment. I now create a financial model to determine if the facility's cost structure will allow you to have a financially successful event before signing any hotel contracts.

Another commitment is choosing and publicizing the registration fee. We can decide on a particular registration fee, but until we publicize it, it's just a decision. The minute we start spreading the word it becomes a commitment. Sure, you can raise the prices, but that will often backfire, especially given that people tend to check out a conference the minute they hear about it and then defer (or procrastinate) signing up for it until the last minute. On the latest event I am helping with, we have decided to resist the urge to set a registration price until we have a better handle on the cost structure of the event. This is a delicate balancing act; we want to set the right registration price, but we want to get the word out soon enough to give people a chance to sign up. Chances are we will still have to make some assumptions when we make our pricing commitment, but at least we will be more informed than had we set the price today.

Financial Models Don't Have to Be Complex

So you would like to try building a financial model for your project, but you are worried that you will have to spend hours staring at a spreadsheet full of arcane equations to do it. Not really. The conference financial model described above uses nothing but simple math. Remember that it is a model, which means that while it approaches reality, it does not have to land squarely on top of it. You need a certain level of detail to make the appropriate decisions, but what you should really focus on is gathering the appropriate financial information and organizing it in a way that is easy to update and understand. Then it is just a matter of having the discipline to keep it updated and play around with it when you need to make a certain decision. It can even be a fun diversion from project planning or chasing down project issues for a couple of hours.

User Illusions

2008-04-14T15:17:02-07:00

by Kent McDonald

The daily standup was progressing as usual, until Vince's turn. "Well, yesterday I worked on the address screen for a while, and then I moved to the credit card entry screen, and then I messed around a little with the report request screen. Today I plan on working with the address screen, the credit card screen, and the report screens a little more. I don't have any obstacles."

Gina, looked at him quizzically and asked, "Why aren't you working on one thing at a time instead of jumping from one thing to another?"

"Oh," replied Vince a little irritated, "because I get so far on one thing, then I need to ask Todd a question about how the users want it, and he says he has an idea, but he wants to clear it by Mary, Joe, and Polly first. It seems like they always get back to him right away, but they always have different viewpoints and they can't come to a clear decision."

"Humph," chimed in Kim, "I wish Todd would just make a decision. It seemed so much easier when we just did what we knew was right. The customers never seem to know what they want anyway, or at least be able to agree."

"Yeah, no kidding," said Gina. "But when we started doing this, we insisted on having one customer to talk to and to have them with us all the time, and Todd is who they gave us. He's a good guy, but he has only been with that department for a couple of months. Where is Todd anyway?"

"He went home with a migraine," said Vince, looking at the Task Board wondering what other task he could get started on that wouldn't be a big deal if he didn't finish right away.

At least we know who to blame

Agile advocates like to brag that one of the advantages of agile methods is that they stress regular involvement of the "customer" throughout the life of the project. In fact most of the methods establish a clearly defined role and call it various things, including customer, product owner, and expert user. Although the terms are different, they generally expect the role to do the same thing—tell the developers what functionality to work on, and in what order, and provide timely feedback on functionality so that the developers can respond accordingly. These methods take things a step further and also stress the need for a single customer providing this information. Some people refer to the concept as the "single wringable neck."

This view on customers is rather shortsighted and ironic coming from a community so focused on collaboration. Very rarely will you find one person that has the necessary breadth of knowledge to address questions surrounding the business needs of the project and the detailed user needs, such as the best way to display the address fields or how fields should be laid out on a user interface.

In some cases, the manager of the area requesting the project is assigned to the team as product owner. In this case, the team may be able to get a good feel for the business need for the project, but chances are they will not get the best guidance on how the application should be designed for the actual user. Sure, the manager knows what they want, but chances are they are not working with the application on a day-to-day basis, so they provide guidance based on how they think the work happens, not how it actually does. The end result is product that provides the necessary functionality, but doesn't come close to doing it in a user-friendly manner. That is, assuming that the team is able to get an appropriate amount of the manager's time, which is often not the case.

Alternatively, an expert user may be assigned to your team. You would prefer someone who could do the job in their sleep, but those are the folks that are often tagged for every project, so you often get someone from the business that has a relatively good grasp of the process, but is not crucial to the operations. This also means that they may not be confident enough or have the authority to make critical decisions when it comes to prioritizing business functionality. They inevitably have to go back and ask their manager—you know, the one who did not have enough time to be involved with the team in the first place.

In both cases you get a single customer, but the advantages of their team interaction are diminished because they are not available, or they are not able to make the key decisions in a timely manner. And don't forget you haven't eliminated the frustration of dealing with multiple stakeholders with conflicting needs. You've just shifted it all to the "product owner," who may not have the skills, training, and experience necessary to cope with it. No wonder Todd has a migraine.

It Takes a Village

Instead of demanding that a single person represent the business point of view on the project, you will be much better off if you realize that requirements come at different levels of detail, and that different people are best suited to make decisions about each of those levels. Instead of thinking of a monolithic customer, I prefer to think of the business side of a project in four distinct roles: product owner, customer, stakeholder, and user. These roles aren't based on what they do on a project, but on what decisions they make. The following table shows these four roles, their description and the decisions for which they are responsible.

Role	Description	Decisions
Product Owner	People responsible for the desired impact of the product on the business	Features included in product
Customer	People who will buy the product	Problems needed to be solved
Stakeholder	People impacted by the existence, use, or sale of the product	Product impacts to their organization
User	People who use their product on a regular basis	Detailed characteristics of the product, especially surrounding the interface with people using the product.

Keep in mind that "product" has different meanings depending on the context. In a product development project, the product is whatever is sold externally. For an internal IT project, the product might be a software application created to support a business process. In these internal projects, the customer and product owner are often the same role, in that the person "buying" the product is often also responsible for its impact on the organization.

This distinction is important when you consider that requirements can be classified into at least three different levels of detail: Business Requirements, or the features included in a product; User Requirements, which provide guidance around how someone uses the system; and System Requirements, which provide constraints around how the software is crafted to support user and business requirements. If we were to revisit the above table and include consideration of what requirements they provide, it would look something like this.

Role	Description	Decisions	Requirements
Product Owner	People responsible for the desired impact of the product on the business	Features included in product	Business Requirements
Customer	People who will buy the product	Problems needed to be solved	Business Requirements
Stakeholder	People impacted by the existence, use, or sale of the product	Product impacts to their organization	Business Requirements
User	People who use their product on a regular basis	Detailed characteristics of the product, especially surrounding the interface with people using the product.	User Requirements

What this tells us is that we have to chat with more than one person to get a complete picture of the product, and we have to realize that different people will provide different types of information.

So I am back where I started!

"But Kent," I suspect you are saying, "I could never possibly have all of those people involved with my project all the time. I can barely get one person dedicated."

Yep. But here's the trick: even though the product owner, customer, and stakeholder all identify business requirements, only the product owner is really responsible for deciding which business requirements—which features—are actually implemented, because they are on the hook for the success of the product. Additionally, when a team follows an iterative approach, decisions about which features to realize do not happen on a continuous basis. Rather, they occur at the beginning of each iteration when the team plans their work for the next couple of weeks.

The types of decisions that do occur on a regular basis are those related to how users interact with the system, so there is still an advantage to having a user work closely with the team on a day-to-day basis. The key is that the user working with the team has to have the appropriate knowledge of the product and business process, and must have the ability to make the appropriate decisions in a timely manner. In cases where the user working with the team faces a group of vocal peers, such as in Todd's situation, members of the development team need to help facilitate the discussions to reach an appropriate decision. The user also needs the appropriate authority to make decisions about user requirements so they do not constantly have to get in touch with the product owner.

Sometimes questions will come up during the iteration that require the product owner's input. In those cases the product owner needs to be available to provide a quick response. Depending on the availability of the product owner, this can be handled in a variety of ways. The team might contact the product owner when questions come up and have an agreement to get answers back within a certain time frame. The product owner might stop by a couple of stand up meetings per week, or have office hours so the team knows when the product owner will be available. The important thing to remember is that the team should not be constantly hitting up the product owner with questions, but rather only bringing up the ones that the product owner needs to answer—leaving the other, more detailed questions for the users who are working with the team on a regular basis.

Knowing who to ask is half the battle

While the concept of the single customer seems an ideal way to simplify the handling of requirements, it often leads to other challenges that could potentially slow the team down. It's important for development teams to realize that they have a responsibility to help the business make decisions by facilitating their discussions and providing them the appropriate information. Doing so may mean a little extra time, but in the long run, it will result in a more effective team, and potentially fewer headaches.

Related Items
Project Escalation Guidelines
Scope issues, major tradeoff decisions, and serious resource conflicts are all examples of situations that can require escalation to higher management.

Agile Technique Guideline: Stand-up Meetings
Agile project teams are all about collaboration and cooperation -- working with each other, not working for the project manager. This guideline explains how to use one common agile technique -- standup meetings -- to get team members into the habit of keeping each other in the loop without spending hours every week in endless, agonizing status meetings.

Agile: Overview and Core Methods
This paper by ProjectConnections Director of IT Content Kent McDonald provides an overview of the key historical statements created by members of the agile community to codify the value set and principles shared by agile software development and agile project leadership methods. It includes some of the history behind the creation of these statements and suggestions for applying these values and principles in a non-agile environment.

A Fool With a Tool

2008-04-10T10:48:34-07:00

by Kent McDonald

Wanted: A Silver Bullet

You can see it coming a mile away. A project team runs into a problem managing requirements, keeping track of their project schedule, tracing their tests back to their requirements, or some other activity crucial to the success of a project. They get together (good sign) to discuss what they should do to improve their situation and inevitably the suggestion comes up, "if only we had a tool to do that..." And so it begins.

Teams often look at tools as the silver bullet to slay all of their problems; and when used correctly, they can keep most werewolves at bay. Thing is, tools can also cause more problems than they solve, especially in the hands of those not completely prepared to use them.

The Problems That Tools Cause

Not too long ago I heard about an organization that was having difficult keeping their projects under control. They struggled with selecting the projects on which they chose to focus, and with managing those projects once they were underway. How did they choose to improve their project management approach? They bought a Project Management tool produced by a large software company, and purchased training on that tool for the people who are the most active in their projects.

None of the people who attended that training hold the title Project Manager. Rather, most are managers or executives who manage teams of people and are responsible for leading projects. Throwing a project scheduling tool at a group of people who had only a cursory knowledge of that discipline, and then only providing them training on the use of the tool-not the art and the science of the discipline-created a group of people so focused on the nuances of the tool that they completely lost sight of the realities of leading and managing projects. You know, things like managing risks, removing obstacles facing the team, and making timely and value-based decisions. At least they followed my advice to not bother with the resource leveling feature.

This little story—true I'm afraid (you can't really make this stuff up)—highlights a common misconception among teams and organizations: that you can learn a trade simply learning its tools. Training a bunch of people on a project management tool with the expectation it will make them project managers is akin to training someone on a spreadsheet program and expecting them to be an accountant, or training them on word processing software and expecting them to become a novelist. (I would have said writer, but could then anticipate the emails, "Yes but Kent, you know how to use a word processor and you claim to be a writer...") There is a lot more to being an accountant or a novelist than simply using their tools, just like there is a lot more to leading projects than knowing how to use software that helps you create project schedules. There are all of those nuances that you learn through experience, or through mentoring from someone who has slogged through it before.

Of course, there is some value in giving people the basics of the trade that coincide with the use of the tool. That information can serve as a foundation while they gain the experience that teaches them all of that nuance. But what I often see happen is that when someone's only understanding of a trade is how to do it using a particular tool, their initial deepest understanding of that trade is colored by how that tool requires you to do things. At the organization I mentioned above, their impression of project management comes down to the mechanics of using the tool. You hear phrases like "I spent all day trying to add tasks to this tool only to find that I can't save them." Or, "I spent all afternoon trying to close tasks but the tool won't let me."

Problems of a different sort can arise if you have people on the team that know the trade but do not put a great deal of forethought into their tool selection, or (*gasp*) have it selected for them by people that don't do that particular task on a day to day basis (that never happens, does it). In those cases, the team becomes stuck with the particular way of doing things that the tool is based on. They also use the tool as an excuse to not change processes that are not working. The ferocity of this argument increases exponentially with the initial price tag of the tool. "Sure that sounds like an easier way to do things, but how do we do that with this tool? We invested so much in it, we have to keep using it."

Solving the Tool Problem to Solve Your Project Problems

So what are teams to do? After all, there are cases where tools are extremely helpful to a project team, especially where there are repetitive tasks that could be automated, freeing up the people on the team to focus on those tasks that require more thought. Examples in a software development project are things like automated builds, automated tests, and configuration management systems. Below I provide some things for a project team to consider when they think they need a tool.

What is the job that is to be done?
The minute that the idea for applying a tool comes up, the teams needs to make sure that they have a clear understanding of why they think a tool is necessary. What do you expect a tool to accomplish that is so much better than doing it without a tool? This is especially important if you sense that a specific tool is being recommended because someone saw it and thought it would be really neat. They rarely say this, but often it is a solution in search of a problem. This same question needs to be asked when the use of tools is being dictated by "the process" or by the PMO. Does the use of the tool actually add value to the project, or are you using it simply because you were told to do so?

Treat the selection of a tool as a mini project.
When it comes down to it, selecting a tool is very similar to any other packaged system purchase. Generally speaking you would not make a major purchase without knowing why (see above), knowing what you are looking for (i.e. requirements), and having some idea of when you will be satisfied with your selection (selection criteria or acceptance tests). Most of the time, selecting a tool-unless you have multiple to choose from in your organization-is a major purchase. Of course, you don't want to go overboard and put too much process around the selection decision such that it impedes progress on the actual project. After all you don't want to waste all of the business value that would be gained from the use of a tool in the selection process. Gather enough information to make an informed decision, but don't waste time doing it.

Bigger is not always better.
The main purpose of tools is to help automate repetitive activities or those things that do not require human brain power to accomplish. Often times, simple tools that are highly flexible can be used to realize most of the value from applying a tool with hardly any of the cost. I have found that spreadsheet programs can perform a vast majority of tasks for far less cost than specialized tools. Plus, in some cases, building a model for performing a particular task using a simple tool actually helps the project team build a better understanding of the nuances of the trade. In some cases, even a spreadsheet or word processor is overkill. Depending on the situation, sticky notes, a whiteboard, and dry erase markers are sufficient and preferred, especially in the case where uses of a tool prohibit collaboration, such as a requirements management tool which leads the team to interact with the requirements management system in stead of each other and their stakeholders.

Don't let the tool dictate your process.
When selecting a tool, make sure it supports the processes you currently follow that work. If the tool drives your team to use a different process, make sure that process makes sense for the project team and that particular project. Most tools that you bring in will have lots of shiny new features. Resist the temptation to use them unless they directly support what you are trying to accomplish, and don't feel compelled to use a feature simply because it exists. Remember, the tool was built to appeal to a wide variety of users, so there are bells and whistles that you probably don't need and could get in your way.

Don't Be Foolish

So the next time you sit in a retrospective and get into a discussion about how the team needs to be better at understanding how to schedule a project and they read an product review about a great tool that will do just that, engage them in a friendly conversation about what problem they are actually trying to solve and what makes the most sense for your team. Then whip out a stack of sticky notes and a pen and suggest there may be an easier, less expensive, and more collaborative way to do it.

Related Items
Tools for Teams: Beyond the Email Bottleneck
A slightly different take on the tools conversation—how do you know when you need one, and how should you implement it?

Agile Technique Guideline: Information Radiator
Kent explains a simple technique for addressing an often complicated problem. Sticky notes are used in abundance.

Agile Technique Guideline: Stand-up Meetings
Another example of elegance through simplicity. (And more sticky notes.)

Project Management Software Tools Evaluation
Determined to have a tool? Make sure it's got the right features.

Resource Leveling Using MS Project
Dead set on using resource leveling in spite of Kent's advice? Here's how.