Getting Things Done

It has been a while since my last post - good things happening at work, bought a house, and life has been very busy. Luckily, a conversation with a co-worker reminded me of the importance of "smelling the roses" - in order to grow, one must make time to reflect, and the blog is a perfect medium for outloud thinking and reflection. Reading is another area that suffered - I've been trying to finish Getting Things Done by David Allen for a couple of months now, and I am still only half way through.

That said, the book added immediate and significant value to my life by suggesting a very simple concept: filing. If you are reading this at your desk, chances are you have random papers here and there, and they seem to linger and plant strong roots encouraged by the blueish light of the computer screen. I've had this happening at work to some extent, but the situation was much worse at home, as the amount of paperwork on the loose was balancing between irritating and overwhelming.

The filing approach advocated by Allen rests on the following premise: if something (like a piece of paper) can be dealt with in under 2 minutes, it should be done immediately. Otherwise, it needs to be either thrown away or filed (I am somewhat oversimplifying so read the book to get the complete picture).

The filing system must meet two criteria:

1. Filing is easy and quick. This is accomplished by having your filing cabinet, blank paper folders, and labels within reach so the entire process takes literally seconds.

2. Things you file can be easily found. This is accomplished by sticking to a straightforward alphabetical system.

I already had a filing cabinet and only had to buy a box of folders and labels; in the next day or so a giant, shapeless pile of miscellaneous papers, from bills to post cards, has disappeared into the drawer, purged and organized, and since then finding that fishing license or an expense receipt has been a breeze.

One caveat: I also use Neat Receipts for anything that can be scanned. This brings down the amount of papers to be filed, and Neat Receipts has a pretty good search capability so finding things in it has never been an issue.

Bottom line: get a filing system in place, and you will stop wasting time trying to find an important document. You'll just open your filing cabinet, and it'll be right where you think it is.

Getting Things Done and Presenting to Win

I started reading Getting Things Done by David Allen and found that his approach to planning has a lot in common with Jerry Weissman's Presenting to Win.

According to Allen, when you plan, you want to brainstorm first and then organize your ideas. Weissman preaches that you should think of all things you might want to cover in your presentation and then organize them into logical blocks.

Two books on two different subjects, and yet the path to success is the same in both. Nabokov once said that the entire body of literature has 10 universal stories (love, hatred, betrayal, etc.), and each new book is merely a variation and a combination of those ideas. Drawing a parallel with commonalities in professional, non-fiction books, I would think that when more than one book talks about the same principles, there's a chance that those principles might be universal. When I throw in the fact that each of the two books in question led many people to new heights in their career, there's a good chance that these principles are universal and should be studied and practiced.

I am only one quarter of the way through the book, and the learning has already begun! More to come.

The Boomerang Theory

I had a great, very educational lunch with a friend of mine Josh today, and he talked to me about boomerangs. Here's how the conversation flowed:

Josh: What would you expect to happen if you threw a boomerang?

Sergey: I would expect the boomerang to return to me.

J: How do you know it'll return?

S: Well, that's what boomerangs do.

J: Have you ever thrown one?

S: No.

J: If went to the field now, how much money would be willing to bet that the boomerang would return?

S: How about 5 bucks?

J: How about $400,000?

S: I wouldn't. I have never thrown a boomerang, and throwing it may require a technique I don't know.

J: Ok, so what would you do if threw a boomerang, and it wouldn't come back to you?

S: I would fetch it and throw it again, trying a different way of throwing it. I don't know what the difference would be. Maybe I would flick my wrist more.

J: And if it failed to return again?

S: I would try again and do something different again.

J: So eventually the boomerang would come back?

S: Yes.

This brief conversation desribes 2 critical components of success:

1. In order to succeed, one must be willing to fail. The boomerang (a new business, career, girlfriend) may not fly on the first attempt. What you learn from this experience is a way to throw the boomerang that doesn't work.

2. In order to succeed, one must do something different when trying again. When you try again, you have to change the way you throw the boomerang.

In other words, succeed by not being afraid to make mistakes and learn from them.

A Secret Weapon for Building Strong Teams

I am reading an excellent book called Unlock Behavior, Unleash Profits, by Dr. Leslie Braksick. The book talks about using behavioral science to bring about desired behaviors at the individual and organizational level. Correlating the content of the book with my professional experience in the PM field, I realized that most Project Managers miss out on a great opportunity to make their projects more successful by not taking advantage of the behavioral science.

In my career as a PM, I often see my fellow PMs focus on budgets, timelines, requirements management, scope management, issues logs, risks, and a million other things related to the project. I rarely see PMs focus on professional growth and development of their team members. In matrix organizations, team members don't report to the Project Manager, and PMs assume that professional growth and development of the team is not their responsiblity. Moreover, many feel they have little control over the team members' performance, since they hold neither the carrot nor the stick and thus can't adequately reward or punish the team members to optimize their behavior.

Fortunately, the behavioral science provides us with two mechanisms that don't rely on the ability to give or to take away tangible rewards. The mechanisms I am talking about are Feedback and Shaping.

For every behavior, there's an antecedent (a trigger) and a consequence. Feedback is one of the forms of consequences; it can re-enforce a desired behavior or lower the likelihood of an undesired behavior. Feedback doesn't cost money; you don't need to control a person's salary or bonus to give it. Yet, it can yield amazing results if done right.

While I would highly encourage you to read Chapter 5 of the book to get a comprehensive review of the feedback process, here's a quick summary of what constitutes effective feedback, in Dr. Braksick's view:

1. Make it specific. Don't just tell somebody they did great. Focus on details.

2. For every piece of constructive feedback, give 4 pieces of positive feedback. Remember, positive feedback re-enforces behaviors you appreciate. Constructive feedback is often aimed at stopping or changing behaviors you don't appreciate.

3. When providing constructive feedback, focus on the issue, not on the person.

4. Deliver feedback soon after the behavior occurs; otherwise, you may forget the details, and the person on the receiving end may have difficulty recalling the details of the behavior.

5. Be sincere. If you don't mean it, don't say it, as your tone of voice and your body language are likely to give you away, even as your words paint a different picture.

6. Give feedback often. It is free; it gives you the power to influence other people's behavior, and people will view you as a leader.

7. Avoid giving no feedback. No feedback is the worst option you can opt for. It neither re-enforce nor blocks a behavior, leaving the person guessing whether what they did was good or not.

8. Don't refrain from providing people with positive feedback. Remember how good you felt the last time someone gave you a specific and sincere praise? Make a day for other people by helping them feel noticed and cared for.


More in Shaping coming soon...

Ensuring Success of Intranet Implementations Through Behavioral Changes

The thought of the day: the ROI of Intranet implementations can be measured by changes in behavior.

As a consultant, I've witnessed and participated (guilty as charged) in numerous Intranet projects that were initiated and executed without a clear understanding and definition of KPIs, which would define the ultimate success or failure of the project. When the economy was good, companies could afford some inefficiency, and healthy revenues were sufficient to cover pet projects, projects related to performance reviews, or “everybody else is doing it” projects.

Welcome to 2009. Sales are flat; layoffs hit the best of the best, and analysts are cautiously pessimistic. For a savvy consultant, this is an excellent opportunity to demonstrate their thought leadership to the clients and assist with choosing projects that will deliver measurable value.

I already wrote about the importance of thought leadership for a professional services firm as one of the enablers to charge premium rates and avoid “who’s cheaper” competition. During an economic downturn, the thought leadership in helping choose the right projects by defining KPIs and identifying a clear path to reaching the targets is how you can carve out a niche for yourself; instead of having to beat competition in a bidding war, you will create your own playing field and will be the only player on it for a while.

Another way to look at this is to go beyond cost and ability to execute as selection criteria for vendors. It is very hard to sell a $100,000 project to a client unless you can make a clear case that the project will save or earn as much, with a relatively short payback period. With a sold proof of expected ROI, your client will have a much easier time selling the project to their boss and will also earn some points as a strategic thinker with management skills written all over them.

Now, here’s the challenge. Defining KPIs for Intranet projects is tricky. It is something that the best of the best struggle with, as I’ve personally witnessed. One of the reasons for this struggle is that Intranet projects aren’t directly tied to revenue or cost reductions. You build a new Intranet portal for an organizational group or department, and in the end the same number of folks are doing the same jobs with the same level of efficiency, bringing in the same kind of revenue.

The second challenge is that simply saying that Solution X will save every user 10 minutes a day or Y millions of dollars a year falls on deaf years. While the savings may look impressive, the cost of labor doesn’t change, and the client still has to figure out as to how to translate the 10 extra minutes to more revenue or lower costs. Unless you can help them and come up with a clear plan leading to improvements in the bottom line, your solution is half-baked.

Let’s take a step back and forget the technology. Instead, let’s focus on one of the key success factors of any project – a change in behavior. When something new is introduced in an organization, the natural expectation is that somehow it’ll change the behaviors of people affected. This new factor could be a new strategy, a new process, a new organizational structure, or a new information technology. Before the new element is introduced, the company identifies the behaviors it seeks to change and creates a vision for the future behaviors it wants to form through the change. When the injection of the new element is completed, the outcome is very clear: the new behaviors are either there or not. The Intranet implementations should follow the same rules, and here’s how you, as a consultant, can help your client with Intranet implementation and help yourself win more business.

Identify the behaviors your clients should promote. This is your chance to show your knowledge of the client’s industry and bring to the table some best practices that exist, or better yet, will exist in other organizations or other parts of the company. You don’t need to engage in a complex business process re-engineering exercise (sounds old school, doesn’t it?). The client is not paying you for this; unless you are trying to sell millions of dollars worth of technology services, your sales budget will be fairly limited. The good news is that organizations in a particular vertical or market segments have lots of similarities so you won’t need to re-invent the wheel on every engagement. Instead, you want to identify a handful of key, fairly generic behaviors that would be applicable in 80% of the situations. Examples of these behaviors might include:

• Seeking help from other people in the organization. Every organization has a lot of tribal knowledge. Documenting this knowledge takes time and can be expensive; in addition, a quick phone call with 1-2 questions is often all the help seeker might need. Therefore, you want to encourage a behavior of finding an expert in a particular area and instantly connecting with them.
• Sharing knowledge with co-workers and/or clients. I blog, because I believe I have some ideas that could benefit others. I get satisfaction from knowing people read my blog posts. I blog, because I am building a thought leadership image of myself that ensures that my clients feel good about paying premium rates for my services.

Now that you’ve identified the behaviors you will help your clients promote, let’s take a quick de-tour into the behavioral science. The ABC model of creating behaviors looks like this:

Antecedent -- > Behavior < -- > Consequence

The antecedent is a trigger. Anything that prompts the behavior to occur is an antecedent. For instance, if James the Manager asks her subordinates to actively seek help from other co-workers, that’s an antecedent. An antecedent may or may not lead to the behavior; in fact, antecedents contribute only 20% to the behavior occurrence. The other 80% is driven by the consequence. If the consequence is positive after the behavior takes place, the person is very likely to re-engage in the behavior, and vice versa. If Jennifer the Account Representative listens to James and tries to seek help, she will look at a) whether the help was pertinent and got her over the hurdle she was facing and b) how easy it was to find the expert she needed. Therefore, if your solution paves a smoother road to positive consequences, Jennifer will be more likely to ask for help and thus perform the behavior James expects.

Now that you understand that you need to identify behaviors that will positive affect your clients’ business and tie your solution to the consequences of the behaviors, let’s come up with measurable KPIs for each behavior. Many times I’ve seen situations where a project is started without defining specific and measurable results that will determine the project’s success or failure. As a famous Chinese proverb goes, if you don’t know where you are going, you are unlikely to get there. Unless you know what your Point B is, how will you know that the client has reached it? How will the client be able to communicate to their boss that the project is a smashing success unless the definition of success is agreed upon up-front, without ambiguity?

Using the examples of behaviors above, here’s how your KPIs might look:

• Seeking help from other people in the organization. If your solution reduces time it takes to find an expert in a particular area, resist the temptation of calculate the amount of time you save the company. It is not only meaningless, but also doesn’t show an increase in the behavior the client is trying to promote. Instead, you could use metrics like the number of searches for experts and the amount of time each search took. While the former should be defined together with the client, the latter is part of the value proposition tied to the solution you are selling.
• Sharing knowledge with co-workers. I use Blogspot for my blog. Whenever I insert an image into a post, the formatting gets all screwed up, and I have to go through the text and waste my time manually deleting blank lines Blogspot adds between paragraphs. Then there’s the promotion aspect. I want people to read my blog, and once I make a new post, I go to Yammer and Twitter and tell the world I wrote something new. My KPIs could be the amount of time it takes to post a blog entry and the number of promotional appearances the new entry makes on related sites.

The type of consequences we have discussed above is referred to as Negative Reinforcement. A negative reinforcement occurs when a consequence that might otherwise block the behavior is removed. In both examples, we are removing the inconvenience of spending too much time to complete a useful task.

While the negative reinforcement does lead to a change in the behavior, it only leads to just enough behavior to avoid the negative consequence. In other words, if an employee needs to find an expert to seek assistance from, they’ll be more likely to use the Intranet solution that shortens the path to Point B. The behavioral science teaches that it is a positive reinforcement (adding a reward consequence) that can truly promote the behavior. Hence, in addition to measurable negative reinforcements such as time savings, you need to identify positive reinforcements and develop a program that will promote them to the target audience. Only this way, you will have a truly comprehensive solution that will include technology and a plan to ensure the adoption.

Going back to our examples, the positive reinforcements could take the following form:

• Seeking help from other people in the organization. The reward of this behavior is information that benefits the seeker. So glorify this consequence. Have a communication plan in place to explain the correlation between the behavior of seeking assistance and company goals. Allow for a feedback loop so people can post thank-you notes when they receive useful information. Build a mechanism to convert the tribal knowledge exchanged between two people into searchable content.
• Sharing knowledge with co-workers. Get a rating system in place so people sharing knowledge with co-workers can get feedback on their contributions. Tie the knowledge sharing to annual reviews. Give public praise and acknowledgement to active contributors and exemplify their contributions in front of their peers and bosses.

Summary

Companies have difficulties measuring the ROI of Intranet implementations. A savvy consultant can overcome this challenge by using his industry expertise to identify desired behaviors that will benefit client organizations should they choose to use the consultant’s solution. In order to ensure the client’s success and win the business, the consultant should propose a comprehensive program of antecedents and consequences that will lead to the desired behaviors. Establishing KPIs for consequences to measure and evaluate the outcome of the solution implementation will help the client quantify success; establishing a program of positive consequences and removing negative consequences will ensure the high adoption rate of the solution.

Beat Competition by Focusing on a Non-Core Benefit of Your Services

When Nokia decided to enter the cell phone market, they envisioned that cell phones would become as much of an accessory as a communications device. To live up to this vision, Nokia designed a swappable faceplate so consumers could change the color of the phone to match the clothes they were wearing, without having to buy multiple phones. The rest is history: Nokia became the world's #1 manufacturer of cell phones leaving the original inventor Motorola in the dust.

When Dell began manufacturing PCs, many companies were already producing fast, reliable, and reasonably priced machines. Rather than competing on the dimensions of processor speed, RAM size, or price, Dell made a bet on a unique sales channel. By allowing consumers to order PCs from an a la carte menu over the phone or on the web, the company put people in full control of what they were getting. A windfall of revenue followed, and Michael Dell became one of the richest men in America.

The examples above illustrate how companies can differentiate themselves from competition by focusing on a non-core benefit of their product. This post is about how this principle can be applied to a professional services business. Keep in mind that the techniques I am offering here do not replace, but compliment the core benefits you bring to the table: integrity, professional skills, and the ability to deliver on time and on budget.

Non-core Benefit #1: Promotion

Position yourself as a vehicle to deliver your clients a promotion. When talking to them, move beyond the corporate goals and ask them how the project can benefit their personal career. Learn about commitments they made to the management. Help them define what their personal success will look like and build your solution around this definition. Once you win the business, always keep that personal success in sight and continue to prove that you are on track to achieving it.

Non-core Benefit #2: Thought Leadership

Provide your clients with free ideas. As you work on the project, set aside a day to bring together your best experts, brief them on the situation the client is in, and have a brainstorming session to come up with ideas that might help the client achieve their strategic goals. Pick 1 or 2 ideas, work them into a solution, and then invite the client to a free seminar or presentation and share with them what you came up with. Naturally, you may miss the target, but if you hit the mark, guess who’ll be doing the work to implement your ideas? Either way, the client will be pleasantly surprised, and you’ll gain a reputation of a thought leader – a position that allows consultancies to charge premium rates.

Non-core Benefit #3: Manage Up

If your client has to report to their boss on the progress of the project, ask them how they communicate the status. If the vehicle is a PowerPoint deck, take the time to put together a few slides that the client can plug right into their deck without making any significant changes. If it is a written report, write up the section about your project. Make it easy, make it look good and read well, and you will draw the attention of the client’s boss and will entice the client to talk to the peers about what a wonderful vendor you are.

Non-core Benefit #4: Celebrate the Client’s Success

Throw a party for the client when the project is completed. Help the client feel that it is a true celebration of their success, but don’t go overboard. Keep things light; make jokes at your own expense; ask the client to give small awards to your team members (you buy the awards!). Put together a funny completion certificate that the client will be inclined on hang on the wall of their office. Invite the boss. Invite the peers. Have everybody in the room wish they were the client.

The Power of Opposing Forces

Every day, you get hundreds, if not thousands of chances to observe the amazing power of opposing forces. Just look up at the sky tonight and find the Moon. The centrifugal force is trying the throw it off the orbit, while the force of gravity is pulling it towards the Earth. The delicate balance of those forces is what keeps the Moon in place. If one of those forces weakens, we will either lose our satellite or witness its spectacular crash-landing in someone's back yard.

The same metaphor applies to software development. The Product Manager pushes hard to get more requirements implemented sooner. The development team pushes back on the requirements and asks for more time. I would postulate that the project is healthy when these opposing forces are in equilibrium.

The responsbility to maintain the equilibrium lies on the shoulders of both parties. While the Product Manager should obviously refrain from making wildly unrealistic asks of the development team, making too few asks will cause the project and product to lose momentum and stagnate. Too many asks, and the team will eventually burn out causing a loss of resources and product quality. On the other side of the fence, the development team can't obviously say no to every single request from the Product Manager, but they shouldn't be agreeing to everything either. Through the process of carefully evaluating the requirements against available bandwidth and timeline, the team should push back to negotiate a realistic scope and a realistic timeline for the project. A failure to do that will again lead to a burnout and a loss of quality.

The Scrum methodology provides a reliable mechanism to keep these opposing forces in check. On a Scrum project, the Product Manager is not allowed to change requirements in the middle of a sprint. The development team is expected to commit to a set of functionality they can deliver within a sprint. Keeping sprints short (2-4 weeks) allows the team to tune up their estimates from sprint to sprint, thus ensuring that the team's ability to meet the committments improves as the project progresses.

Scrum may be new for some people, and the fact that requirements won't be locked until the end of the project may be very unnerving to Product Managers (or clients) experienced in the traditional Waterfall methodology. Therefore, educating them on how the Scrum methodology works is a key factor to the success of a Scrum project.

Are You On The Right Train?

One of the questions the Secret (the movie and book) leaves unanswered is what it is that you should wish for. If you think about it, there are so many wonderful things out there you could get or accomplish that day-dreaming about a new car seems pretty meaningless and wasteful.

Yesterday somebody told me a story that powerfully resonates with this thinking.

Two men took a train to get home. As the train left the station, the first man made himself comfortable by the window to enjoy the beautiful surroundings of the area the train was coming through. The second man seemed nervous. He started running back and forth inside the car looking lost and and distraught. The first man distracted from his quiet thoughts lifted his head and asked the second man as to why he was running around. The second man replied that he was trying to get home faster. Why, asked the first man. You are already on the train that will take you home, and all this running won't get you there any faster.

The morale of the story: the most important goal is to choose the right train, as once you are aboard, it'll take you where you want to go. Are you on the right train?

Listen Between the Words

When was the last time you had this conversation with somebody?

You: What's wrong?
They: Nothing.
You: I can tell something is wrong. What is it?
They: I said, nothing. I am fine.

According to the words you hear, the person is fine. And yet somehow, through non-verbal clues and the tone of their voice, you know that they are not.

Albert Mehrabian, a pioneer researcher of body language in the 1950's, found that the total impact of a message is about 7 percent verbal (words only) and 38 percent vocal (including tone of voice, inflection, and other sounds) and 55 percent nonverbal. These ratios were derived from experiments dealing with communications of feelings and attitudes (e.g. like-dislike).

The conversation above is a simple and obvious example of this theory in action. At work, we encounter many highly complex situations where we miss the lack of congruency in the message being said, not paying attention to the clues in front of us.

On a project I recently completed, we presented the visual design of a new application to a client and heard the words that the design was good, give or take some minor tweaks. A couple of months later, the tweaks shaped into a major redesign effort, which could have been avoided, had we listened between the words in that meeting and caught the clues that the client wasn't fundamentally happy with the look and feel of the application.

So, what's in it for you beyond awareness? Here are some tips that can help you become a educated listener attuned to verbal and non-verbal clues:

1. Trust your intuition. If you are feeling that something is off, it is because your brain is processing all of the signals it's receiving, comparing them to each other, detecting incongruity between them, and trying to alert your conscious mind.

2. Check with your colleagues. If you have other people in the meeting, talk to them afterwards and ask for their observations and feelings. If they walk away with the same feeling as you, the chances are your perception is reality.

3. Read some books on neuro-linguistic programming. It'll provide you with an understanding of how you can read and decipher non-verbal clues.

4. When preparing for a meeting, make a mental note that you'll pay attention to the non-verbal language of other people. This will help heighten your sense of awareness.

5. Watch for people's eye movements, posture, and hands. Armed with the theoretical knowledge from the reading and trusting your instincts, you'll be amazed at how much non-verbal clues can tell you.

6. Ask non-threatening questions to validate your assumptions. Circling back to the example at the beginning of the post, you could put yourself in the other person's shoes and say something like this: "If I were you, I think I would feel [adjective], because [reason]. How do you feel about it?" This turns the situation around from confrontational to empathetic; the other person realizes that you are on the same wavelength with you and will be more likely to verbalize what you already suspect.

Highlights and Lowlights in Status Reports

Somebody from Microsoft gave me an idea of using colored arrows for accentuating high- and low-lights of the project on the status report.

It looks like this:


While it is a minor formatting enhancement, it'll help your audience to focus on the key areas, and the use of arrows makes this apporach work for color-blind people as well.

Earned Value and Contingency

April was a crazy month for me, as I was completing two projects and getting ready for a national ballroom dance competition in LA. Now that the madness is over, blogging can regain its spot under the sun again.

Rather than talking about something as abstract as my thoughts on Harvard Business Review, I would like to add to the subject of Earned Value today.

When you plan a project, you always account for some sort of a contingency or buffer (if you don't, you should!). Depending on the complexity and size of the project and the specific approach chosen by the project manager, the contingency could be applied to the entire project or could be calculated against individual summary tasks or even work packages. Either way, at any moment in time you should be able to calculate Earned and Planned value pre- and post-contingency.

All of the Earned Value charts I've shared so far showed a single Earned Value line. In this post, I would like to show you a chart that shows the pre- and post-contingency. Why is this important for both the Project Manager and the client? The contingency is essentially an indicator of how much risk the project can handle. For example, if your pre-contingency Planned Value is $120,000 and the post-contingency Planned Value is $150,000, the $30K delta is what you count on to address any expected or unexpected risks or changes that come up throughout the course of the project. The closer your Actual Cost to the Pre-Contingency Planned Value, the greater you ability to handle risk and changes. As you move closer to the Post-Contingency, you are using up your reserve, and your position weakens.

Showing both pre- and post-contingency Planned Value lines on your reporting chart is a quick way to relay the project risk to the stakeholders.

Here's how you can do this using the Excel spreadsheet I showed you in previous posts.

1. Rather than having a single Earned Value row for the chart data, replace them with a Pre-Contingency and Post-Contingency Earned Value rows:

2. Add the Pre- and Post-Contingency lines to the chart:

Please note that this version of the chart no longer has the Budget line. I am still deciding whether it is useful or not so please feel free to comment on it.

3. Track your actual costs as usual. Ideally, they should be between the blue and the green lines:

First impression of Harvard Business Review

When I was in the undergrad and grad programs in the business school, the profs kept having us read articles from Harvard Business Review. I remember b&w copied they distributed, and back then, it was the most boring and tedious reading I'd ever done.

Now wind forward 10 years, to last week. After paying $80 of my hard-earned money for a 12-month subscription, I finally received the first issue.

Why did I subscribe? Well, I've been reading a lot of business books lately, mostly on Sales and Marketing, and I've found a lot of value in them. Working with a lot of sales and marketing clients, I got a better understanding of their world through my reading. The human mind works by association, and now I go beyond listening to my client talk about their challenges and opportunities and nodding my head - I relate their experiences to what I learn in the books and can ask intelligent questions about their strategy and business. Subscribing to the Harvard Business Review was a logical next step in the learning process.

The copy of the magazine I received had little resemblence to the b&w smudgy copies from the college days. Colors and high-quality glossy paper were a nice surprise (okay, my expectations were really low). The paper is thicker than the paper used by the Economist; I am pretty sure that the publishers did this on purpose to send a subliminal message of the lasting value of the magazine and its articles. It also seems that the style of the articles got a little lighter - but maybe it is just me being smarter now (my girlfriend would disagree at times!).

I am now going through the issue so the next post will have my thoughts on specific articles. Come back on April 17!

Top 10 Success Factors for a Bug Bash

Now that the bug bash I announced in the previous post is over, I wanted to share some experiences about organizing, conducting, and concluding a successful bug bash.  But first, let me tell you why a bug bash is so helpful for a software development project.  Theory aside, here's how my team has benefitted from our bug bash:

1. Effectiveness.  We discovered over 50 issues in 1.5 hours.  Compared to regular testing, it would take a few days to get to this number.
2. Usability Verification.  We received reassurance that the application is intuitive enough that people can use it without reading a user manual.
3. Stability Verification. We received reassurance that the application is stable; out of 50 issues, only 1 was a critical error, and people were able to complete all tasks we asked them to complete.
4. Install Verification.  We verified that the install process ran successfully on different configurations.

With these results in mind, let me now segway to the list of Best Practices we've leveraged to ensure the success of the bug bash.  

Before the Bug Bash

Best Practice 1 - Send an Advanced Invitation

People have busy schedules so make sure you give them enough notice.  In my case, I sent an invite 3 business days in advance.

Best Practice 2 - Set Specific Start and End Times

When scheduling a bug bash, we clearly identified the duration of the bug bash to remove any ambiguity around the time commitment we were asking for.

Best Practice 3 - Invite More People Than You Need

I wanted to have 8 people for the bug bash and ended up sending the invitation to 30 or 40 to get my 8.  Also, keep in mind that even you have enough people signed up, their schedules may change, and you'll be left out in the cold.  So try to book more people than you need.

Best Practice 4 - Invite People from Different Business Groups

Include multiple business groups into the Bug Bash - anybody who is willing to participate should be welcomed (unless your application is highly specialized and requires a deep understanding of a particular domain).  Different groups will bring fresh perspectives to the table, and you'll get bugs from behaviors developers or testers wouldn't think of.

Best Practice 5 - Provide Written Instructions With An Appropriate Level of Detail

Our Bug Bash was for a sales tool.  Sales people don't like reading manuals, and the tool needed to be intuitive enough for a first time user.  To keep the situation as real as possible, we provided our bug bashers with a description of a business situation in which the tool would be used and listed 8 high-level tasks our bug bashers had to accomplish.  We also included a list of known issues in this version of the tool so people wouldn't waste time logging them.

Best Practice 6 - Include A Feedback Form or Spreadsheet

To ensure that the bug bashers would submit feedback in a consistent manner and format, we provided them with a simple Excel spreadsheet with pre-defined columns.  The standard entry format made it extremely easy for our testers to consolidate the results.

During the Bug Bash

Best Practice 7 - Send Out a Reminder To Start and To Finish

Our bug bash ran from 1 pm to 2:30 pm.  At 12:58, I sent out an announcement to everybody who accepted the invitation and reminded them that the bug bash was starting.  Shortly after 2:30 pm, I sent out another announcement letting people know that the bug bash was completed.  Why should you do this?  Your bug bash is a high priority for you.  For your bug bashers, this is an add-on activity that they graciously agreed to do. Sending out the announcements helps them remember their commitment and releases them back to their regular work lives.  

Best Practice 8 - Be Available To Answer Questions

Our bug bash instructions included the team's Distribution List and a request to email us should any questions or issues arise.  We monitored the alias throughout the bug bash and were able to answer a few questions that came in. This ensured that people wouldn't get blocked from completing the tasks we asked them to complete.

After the Bug Bash

Best Practice 9 - Thank Your Bug Bashers

After the bug bash was over, we sent out a Thank You note to all the participants and  listed their names.  That's the least any team can do to express their appreciation of the effort put in by the bug bashers.

 

Best Practice 10 - Triage the Issues and Log Bugs

After our Tester consolidated the feedback of the participants into a single list, the team sat down and went through every single issue together.  We ended up dismissing some issues, raised a few questions to the client and a user experience architect as a result of others, and logged the rest as bugs into our bug tracking program.

Armed with this checklist of best practices, you too should be able to complete a successful bug bash and achieve the following goals:

1. Effectiveness (high ratio of bugs to time spent)
2. Usability Verification
3. Stability Verification
4. Install Verification

Bug Bash coming up

One of my projects is going live in mid April to a world-wide audience of thousands of users, and we decided to conduct a bug bash.

According to Wikipedia, "bug bash is where all the developers, testers, program managers, usability researchers, designers, documentation folks, and even sometimes marketing people, put aside their regular day-to-day duties and pound on the product to get as many eyes on the product as possible."

We are planning to have 8-10 people participate in the bash, and I am sure I'll have some lessons learned to share. Please come back on April 3 for an update.

Earned Value as a Survival Technique for T&M and Maintenance Projects

The Earned Value calculations rely on the assumption that you have created a Work Breakdown Structure and estimated the work for each work package. Works great when you know what you are going to be doing, but what about T&M or maintenance projects with requirements and tasks to be defined as the project progresses? Is Earned Value dead for those? Not so fast. Keep on reading, and you will learn how you can proactively identify budget issues when the WBS doesn't exist.

If you've watched one of my favorite TV shows, Survivorman, you know how it starts for Les Stroud. He looks at scarce things he has available and talks about what he can use them for in a survival situation. In our less dramatic situation, we normally have the following things available to us:

1. Budget. Even though the project may be T&M, more often than not you have the target in front of you.
   


2. Timeline. Even though you don't know what exactly you'll be doing, you should at least know how long the project will last.

This gives us plenty to work with. Below I'll show you two examples of how I survive with only these 2 numbers handy.

Example I - The client told you how much money they have to spend

For the sake of this example, let's say that your budget is $40,000, and the duration of the contract is 20 weeks. You will be providing status updates every other week so your reporting period is 2 weeks. This is a site maintenance contract so you have no clue as to what might come your way.

Step 1 - Calculate the average projected burn per reporting period.

Average Project Burn = Total Budget / # of reporting periods

In our example, Average Project Burn = $4,000

Step 2 - Put these numbers into a spreadsheet.



Step 3 - Build a chart based on this data.



If you need assistance with building this chart, you can refer to one of my earlier posts.

Step 4 - Start tracking.

At the end of every reporting period, I update the spreadsheet with the actual cost incurred during that period. After a few updates, your chart might look as follows:



This is important to you, because the chart provides you the visibility into a potential budget overrun way before the overrun becomes a problem. In this example, you see that for the last 3 periods, the project's actual burn consistenly exceeded the proejcted spend, and if all things stay equal, the project will end up costing more money than originally expected. If you include this chart into your status report, the client will become aware the issue now, with enough time for you and them to figure out an approach to either curtail the scope, improve the team's productivity, or increase the budget. Happy client = No suprises

Example II - Your estimates are resource- and time-based

In this example, you don't know the scope either, but you estimate the project spend based on the expected utilization, rates, and number of resources. So instead of dividing your total budget by the number of reporting periods, you estimate the spend using the following formula:

Spend for Period 1 = # of hours for Resource 1 * Resource 1's rate + # of hours for Resource 2 * Resource 2's rate + ....

To create a chart for this example, you can follow the technique I described in the earlier post and just replace the WBS work packages with reporting periods:

Stay Late, Earn Respect, Build the Team

I recently joined a PMI Certified PMPs group on LinkedIn and couldn't help jumping on a discussion regarding team building exercises. Are they useful or not?

My response was:

"Folks, the best team exercise is the one when you have a deadline, and you stick around in the office with the team even though they are doing all the work, and you are just sticking around to instill the team spirit. A good Project Manager is a leader who leads by example; you have the power to make an impact, and you don't need artificial exercises for it.

On a side note, I play Halo with my developers, I go to lunch with my testers, and I fight for my team in front of the clients. That's what helps me turn people I work with into cohesive teams."

I'd like to elaborate on this a little bit and give you a specific example of earning respect through this.

I recently delivered a project with an absolutely insane timeline - a public-facing web site with a potential audiences of hundreds of thousands. We did it on time and on budget, in 4 weeks. As you can guess, there were some late nights for the team, and that was expected (but not planned for!). As the project started, my Dev Lead asked me if I was the kind of a Project Manager who stays late with the troops until the job is done or goes home. My answer was, dude, of course I'll stick around (I learned the importance of staying up with the team at my previous job from Peter Hammond, the owner and President of CyberSavvy. Thanks Peter!) So a week before the launch, the push actually came to shove, and I stayed in the office until 9 pm with the team. The next day my Dev Lead came by my desk in the morning and said that he appreciated me sticking around and added that if I hadn't, "he and I would've had to have a little chat".

Earn respect and build the team by being there with them. There are few things more discouraging to the team morale than a PM who goes home when the team is burning midnight oil.

Tell-a-friend is one small step for a developer, a giant leap for a company

In early March Ascentium launched a public web site for one of our clients. To my surprise, one of the key requirements for the new site was a tell-a-friend feature aimed at promoting the company's product.

That seemed like a pretty insignificant piece of the functionality to have, and in my humble opinion, there were other features that should've been completed instead. Was I wrong!

Last week I was reading a book called Word of Mouth Marketing by Andy Sernovitz. On page 123, Andy lists three things that the reader should remember even if they choose to ignore the rest of the book:

1. Ask people to spread the word.
2. Put everything in an email
3. Put a tell-a-friend link on every page of your website.

The idea behind the tell-a-friend link is that it is one of the best ways to spread the word. The book also clarifies that tell-a-friend should be as compelling and easy to use as possible, as it gets the company word-of-mouth marketing for free. It often surprises me how little things can prove to be so important, and this is definitely one of them. Lesson learned! After reading the book, I wrote the content for my girlfriend's web site last week (she just opened a family medicine practice in Kirkland, WA), and you'll be sure to find a tell-a-friend link on every single page of the site.

The morale of the story for my fellow Project Managers: understanding the business of your clients is a key success factor for the project. I would argue that it is as important if not more important than the understanding of the technology.

Thoughts on project overages in the context of a consulting company

I was chatting with my PM peers over a brown bag lunch this afternoon, and project overages became a topic of a heated discussion.

In the PMI/PMP world, "on budget" is one of the cornerstones in the definition of a successful project. PMs are expected to bring the project on budget, because:

1. An overage eats into the company's bottom line.
2. It is an easy metric to use; there is nothing fuzzy about it; you are either on budget or you are not.
3. It is a "feel good" psychological statement (didn't you have it on the latest copy of your resume?)

I would like to make an argument that in a consulting company, small overages may be OK.

Here's why.

Most consulting companies have a bench. For folks outside of the consulting world, a bench is a term to describe available resources who are collecting a paycheck but don't have an active project to bill against at the moment. In the ideal world, a consultant on the bench stays productive by taking training, assisting with internal projects or sales and marketing efforts (if my manager happens to read this, blogging is a marketing effort too!), or actually taking care of themselves by enjoying a well-deserved vacation. In the real world, people come to work and surf the Internet, play video games, gel by the water cooler, show up late and leave early.

Since the resources on the bench get paid anyway, utilizing them on a project will have no impact on the profitability of the company, as long as their involvement doesn't interfere with the productive activities listed above or prevents them from joining another project. The potential benefits of using benched resources, on the other hand, are numerous:

1. Rescued projects
2. Happy clients and potential future revenue from referrals
3. Improved morale (sitting on the bench is no fun! there are only so many online training courses one can take at a time)

That said, overages are a re-active, not a proactive measure. Similarly to how overtime is a safety net and should never be planned for (according to PMBOK), overages are a second line of defense and should never be part of the project plan.

So, my conclusion on overages in a consulting company is:

1. When managed responsibly and staffed by benched resources, they cost the company $0
2. They have a number of long-term benefits
3. They are a safety net and should never be planned for

What do you think? I would love to get some comments on this post.

How I Calculate Earned Value for Status Reporting

If you've seen my earlier post on Status reports, I showed you an Earned Value chart that I include on my status reports. This post talks about how I create that chart.

Step 1

Create you work breakdown structure. I bet this term was made up by an engineer. I have a lot of respect for engineers - after inventing the wheel back in the old days, they did many other good things for humanity; some of them invented the wheel again, while others built machines, computers, bridges, and space aircraft. The fella who invented the term definitely falls in the latter category; however, he must have slept through his arts classes during his undergrad, because otherwise he would've come up with a sexier or at least a more common name for a list of work packages. Now, work package is a unique animal in its own class. I am sure the fella's English teacher cried when he heard the term. Don't get me wrong - I've tried hard to use the term, but I keep getting blank looks from everybody on it. Even some PMs! (different story here). I stick to Task. It is something people understand, and everybody knows what a task is.

So, in plain English, get a list of what you are going to do on your project and break high-level tasks into more granular tasks as needed.

Step 2

Enter the tasks into MS Project, Excel, some fancy EPM software, or carve them in stone (the transfer to Excel later on will require some retyping on this one). I use Excel because it is easy, and I know a lot of really good PMs who use Excel.

You'll want to have your tasks as row headings; x-axis is where you'd want to put your time periods (I wanted to say dates, but them remembered that that's part of my dating blog - don't mix pleasure with business). It'll looks something like this:

Step 3

Make estimates. Earned value requires that you convince yourself that you know how much effort or money each task will take. There is a whole bunch of estimating techniques out there so making good estimates is a different topic. However, if there was only one thing you should know about estimating is that you need to get the numbers from people who will actually be doing the work. There are exceptions to this rule, but I would say it stands in 80% of the cases.

Once you make the estimates, you can calculate the budget for each task and add this information to the spreadsheet:

Step 4

Take a break - you deserve it.

Step 5

Add formulas to calculate the Earned Value for every period as the project progresses. The formula I am using in Excel is SUMPRODUCT - it allows you to multiple the values in one column by corresponding values in another column and then calculate the total sum. You'll also notice I use a formula for calculating the ending date of the time periods.

If you were doing these calculations on paper, the Total Earned Value for a given period would look as follows:

(Task 1 % Complete * Task 1 Budget) + ( Task 2 % Complete * Task 2 Budget) + ...

The % complete for every task goes into the cross cells of the table. I use the 0%-50%-100% approach for % complete, because for all intensive purposes, most tasks have little value until they are completed, and calculating a more accurate number in the middle is not worth the effort, unless you have some automated time tracking software.

Step 6

Add rows for Actual Cost and Budget. These will be used on the Earned Value chart so you can visually compare your actual cost with earned value and have a budget line. You already know the budget so you can enter it into the Budget line:

Step 7

Create a chart. I use a Line with Markers chart, but feel free to be more creative. Just remember that this chart type should not be cumulative. For the data, I use the Earned Value, Actual Cost, and Budget rows, and for the X-axis labels, I use the Date row.

Some formatting tips:

1. Pick custom colors for the trend lines and marker, as the default palette doesn't work so well.
2. You might want to tweak the increment on the Y- and/or X-axis to optimize the chart's look.

Step 8

Start tracking. Every week, I update the % complete values for each task, enter the actual cost incurred during that week, and Excel does the rest for me:

In addition to the chart, my status report includes a copy of the table with % complete numbers into my status report. This spares me the effort of writing a section on the work completed and planned.

Simple and easy, kids!

Book review: Fundamentals of B2B Sales and Marketing

I really like riding a bus. I am lucky to have a direct route from my residence to my office, and every morning and late afternoon, I get 20-25 minutes of spare time. What do I do? I read!

I am actually surprised that other people don't do this as much. Some folks listen to some music, but I would say a solid majority just sits there and looks out the window. Maybe they meditate and just think some productive thoughts.

Anyway, I wanted to share with you the latest specimen from my bus reading adventures. Fundamentals of B2B Sales and Marketing by John Coe. I picked up this book on Amazon (http://www.amazon.com/Fundamentals-Business-Business-Sales-Marketing/dp/0071408797/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1236875196&sr=8-1) and actually posted the following review there as well:

"I'd like to offer a different perspective on this book. I am a Project Manager for a consulting company, and many of my projects are for Sales and Marketing organizations. Reading this book helped me better understand the business processes my clients are responsible for, and while it didn't make me an expert in B2B marketing, I can ask the right questions now. I actually took this book to a few meetings with the client and the team and read quotes from it in the context of 'guys, we are definitely doing the right thing - listen to what this book says'.

The book is full of specific details and examples, has a lot of hands-on information that could be applied right away, and its light, almost ocnversational style makes it an easy and enjoyable read."

Bottom line, if you are PM, it helps immensely if you expand your reading horizons beyond PM books. Understanding the client and speaking the same langauge as they do is a major success factors for a project; you will gain respect and SME status both from the team and the client.

Using charts in status reports

A few months ago, I started including an Earned Value chart into my status report and have had very positive feedback about it from every single client. People love it, as charts can provide a quick visual representation of where the project is at a given point of time and can also show a trend.




The chart I am using is very straightforward and looks something like this:


















The chart compares the actual spend on the project vs. the Earned Value - the budgeted cost of the work completed.

In the example above, you see that the Earned Value consistently exceeded the actual cost. My job as a PM is to be able to explain as to what's causing the difference, as many factors are in play here. Here are some examples:

1. We may have overestimated the effort and/or scope. On a fixed price project, that's actually your profit. On T&M engagements, this creates an additional buffer for you. This actually happened on one of my projects; we communicated the delta to the client on a weekly basis and were able to use the buffer to significantly enhance the visual design of the application.
2. We used a cheaper resource to complete the work. When a cheaper resource is used, and your cost is lower, it is possible that the quality of work is lower too. If this is the reason for the delta, it is obviously something the client needs to be aware of and agree to.

I create these charts in Excel. MS Project could work too, but I find Excel easier to deal with; it also gives me more options visually. You can build your own template for this type of chart in 15 minutes, and then for every project, you just plug in your WBS and update the timeline.

Welcome to my blog

Hello everyone,

I've decided to give blogging a try and see if my thoughts on project management might be of use to other Project Managers out there.

A little bit about myself. I am a Project Manager with Ascentium Corporation - a leading digital agency with capabilities and expertise spanning brand strategy, design, development, infrastructure, customer relationship management (CRM), Portals and Collaboration, and business intelligence (BI).

I would consider myself a generalist; I am a strong believer that a good PM can run a variety of projects. Some of my most recent work includes a Silverlight implementation, a WPF client application distributed through ClickOnce, and a number of SharePoint implementation.

What kind of posts do I expect to make? Well, one of my favorite technical areas of project management is Earned Value. I've been using it on most of my projects, and it is a fantastic tool for keeping the clients up-to-date on where the project is today. So definitely expect some posts on Earned Value.

Another area I am very interested in is psychology. There are many PMs out there focusing on wha I call technical aspects of the job - putting together a work breakdown structure, making estimates, etc. However, few people seem to focus on psychology and the understanding of the human behavior - things that are invaluable for a Project Manager.

Finally, you can expect some sales and marketing posts. Since Ascentium is an interactive agency, a lot of our clients are in Sales and Marketing, and I've been doing a lot of reading in this area and have been applying the information I learn on my projects as a value add-on to our clients.