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.