Good Requirements vs. Rework – Part 3

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

As we concluded Part 2, we discussed what we all really already know – that bad requirements usually lead to cost or budget overruns, project timeframe slippages, frustrated and overworked employees, dissatisfied customers, lost profitability, and quite possibly shortened tenure with your company.

The ultimate cost of requirement errors and omissions can be huge beyond just the rework factor. Requirements drive more than just project and product quality. They drive product end-user usability. They drive the personnel skill levels for both product development and operation. They determine how the product will be used. Requirements for ease of operation, for example, lead to products that require less training before use and less time to accomplish tasks. Omitting operability requirements will result in a product that is inexpensive to purchase but costly to use. Worse, end-user operators may make more mistakes in the product’s use. Read more »

Five Key Steps to Closing Down the Project

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

A lot of text and attention is given to how to start projects, and how to run projects. But process of properly closing down a project is overlooked. Why? Well, since I can say from experience that I’ve been guilty of this in the past, here are my reasons, at least:

• Implementation and transition to support happened so moving on seems reasonable
• Have 4-5 other projects I’m also managing
• Just received a new, hot project and I’m preparing for kickoff
• Problem-free implementation means no worries, right?

Look at that list…none of them are good excuses for just basically dropping the ball – and the customer – post-deployment. Things still need to happen, proper hand-offs may still need to be taken care of, information needs to be transitioned. It will happen anyway through frantic phone calls and emails, so why not take care of it in an organized fashion? Because we say we’re too busy…but that needs to change.

Here are my list of five key activities that should happen to ensure proper closure of the project you’ve just finished. Your list may differ and I’d love to hear from you if it does. Feel free to comment and share with our readers here on PMTips.

My list:

• Make sure all pertinent documents and deliverables have been signed off by the customer. You don’t want this coming back to you after the project is over – especially if there are any question marks our payments outstanding.
• Get a final signoff on implementation/solution acceptance. You may have the best relationship in the world with your customer, but don’t skip this step.
• Conduct a lessons learned session with the customer and your team. The information you glean from this type of session can be invaluable to you as a project manager going forward, to your customer as they go forth with the implemented solution, and to your tech support as they provide the ongoing support for the solution with the customer.
• Hold a proper handoff to tech support. Make sure they have all necessary information in order to properly support the client post-deployment.
• Keep in touch with the customer post-deployment. You may have a 30 or 60-day agreement to remain available to the customer and for your team to remain available before the formal transition to tech support. But don’t just drop them at that point, keep checking back. It’s good for your reputation with the customer and for your company’s reputation.

Earned Value Reporting – Schedule Performance Index

In this article on Earned Value Reporting we’ll look at the Schedule Performance Index. The Schedule Performance Index refers to how the project is performing in terms of actually following the project schedule.

Much of the following information came from Newell and Grashina’s book entitled “The Project Management Question and Answer Book.”

What is the schedule performance index?

The schedule performance index is a measure of how well the project is doing in terms of following the project schedule. It is a comparison of the project tasks that were planned to be accomplished to the work that was really accomplished. The index is a value that allows projects of different sizes to be compared.

The schedule performance index is like the schedule variance discussed previously with one important difference. When we calculated the schedule variance, the result was a figure in dollars. If the dollars were negative, the variance was considered bad, and if the dollars were positive, the variance was considered good. The problem with this method is that it is difficult to compare projects of different size to one another. It would be better to have a measure that gives the health of the project regardless of its size. For this purpose we will use indexes.

Instead of subtracting the budgeted cost of work scheduled from the budgeted cost of work performed, as we did when we calculated the schedule variance, we will divide the same two numbers.

SPI = BCWP / BCWS

SPI = EV / PV

We can see that if the project is following its plan, the amount of work accomplished and the amount of money spent to accomplish it are the same, and the resulting value will be one. So, an index of one means that the project is following its plan.

If the budgeted cost of work scheduled is greater than what is being accomplished, the denominator in the fraction will be larger than the numerator, and the resulting value will be less than one. This is a bad condition. If the budgeted cost of work scheduled is less than what is being accomplished, the resulting number will be greater than one and this is considered good.

Example:

A project is two weeks behind schedule at the time of the calculation. The project has fifteen people working full-time. Assume that each person costs $1,000 per week. BCWS at this point in the project is $500,000. What is the schedule performance index?

The project is two weeks behind schedule and there are fifteen people working full-time on the project. This results in being behind schedule by thirty person-weeks or $30,000.

SPI = BCWP / BCWS

The BCWP is $500,000 ? $30,000 = $470,000.

The BCWS is $500,000.

SV = BCWP – BCWS = -$30,000

SPI = BCWP / BCWS = $470,000 / $500,000 = 0.940

Notice that a smaller project such as one that had a BCWS of $50,000 and a BCWP of $47,000 would also have a schedule performance index of 0.940. Again, this helps the project manager who is managing different parts of a project in which the sizes of the parts are different. The schedule performance index, like the cost performance index, indicates the health of the project regardless of its size.

3 More Tips for Working with Virtual Teams

Yesterday I looked at the roles that a clear project vision, excellent communication, motivational strategies and recognising individual differences have on successfully managing a virtual team.  To recap, a virtual team is one where not all the team members are based in the same location: a non-collacted team.  More and more project teams are like this now, as we work in an global marketplace, and with third-party partners.  Here are three more tips for making sure that your virtual team is as successful as possible:

1.   Resolve conflict effectively

Encourage your team to talk to you, and to each other.  One of the problems with virtual teams is that side conversations can take place, and a conflict could be brewing without you even knowing about it.  It’s everyone’s responsibility to handle conflict professionally – and conflict isn’t always a bad thing.  If two members of the team are having a difficult time, you can step in, but only if you know about it.  Therefore, you should encourage an environment where everyone is responsible for proactively identifying and working to resolve conflict.  Issues can be escalated to you where there is the need for more facilitation, but ideally the team can take some ownership for sorting out low-level issues themselves.

Conflict manifests itself in different ways depending on where you are in the project lifecycle.  In the early days, the issue could be lack of cultural understanding or language problems.  Later on, conflict could be caused by differing approaches to solving a technical or creative problem.  The approach to resolving these conflicts is going to be different every time, but you should at least be aware of the possibility that these will happen – and even more alert to conflict than you would be for a collacted team.

2.   Review performance continually

Just because things are going fine today doesn’t mean they will be tomorrow.  You want to be a high-performing team, but that doesn’t happen overnight.  And on a virtual team, it takes even longer.  Think about how you are going to get to a high-performing state – and that means working out what ‘high-performing’ actually looks like.  Chances are it looks like people working autonomously, referring to team members without having to go through you to open the channels of communication, but with regular progress reports and risk and issue reviews – and of course escalations up to you as the project manager.  Discuss what a high-performing team looks like with your team, and then that gives you a starting point on how to get there.

New people joining the team creates an imbalance in skills and experience, so one of your tasks should be to bring new people into the fold as quickly as possible, so plan an induction process as soon as you realise you have a new starter on the way – or someone gives you a clue that they are going to leave!

3.   Handle crises quickly

Projects have crises.  That’s nothing new.  But in a virtual team you have to act quickly to ensure everyone knows what is going on, and how the problem will be addressed.  One of the issues can be ensuring everyone has the same information at the same time, for example, about a corporate strategy change, or a restructure.  With team members in different time zones this can be difficult, and stopping the rumours can be hard.  Virtual team members can feel isolated at the best of times, so you really need to consider getting everyone together for a briefing in these situations, even if it is only on the phone.

Crises and changes can have an impact on the project, and the team will need to work out together how to step up and meet the challenge.  For example, if someone goes off sick and will not be back at work for a while, what impact will this have on the tasks that person will no longer be able to complete?  Who can step in and do those activities, or if no one is available, what impact will that have on the project’s critical path?  Understanding the issues gets you one step closer to being able to minimse the impact on the project delivery.  And of course, make sure you add an entry to the issue log!

These tips are based on my notes from a presentation by Dr Ginger Levin, PMP, PgMP at the PMI Global Congress North America in October 2009, with some of my own thoughts thrown in.  And there are more bits of advice for managing virtual teams in How to Manage in a Flat World, by Susan Bloch and Philip Whitely.