Tuesday, December 20, 2011

How to Tell if Your Customer is Prepared for the Project

We would like to think that our customer – the one who is spending the money – has been diligent in their preparation for the upcoming engagement that you are about to lead for them. It only makes sense, right? If they are prepared, that means smoother sailing, possibly a shortened project window, and a decreased project budget. Cost savings for the customer! A good thing, right? One would think so, but I never cease to be amazed…..

What should your customer come to the table with? Well, at a minimum, they should have the following:

#1 - High level requirements

The customer who comes to the table with no requirements planned out is a huge red flag. Certainly you should expect to help them to some degree with requirements – and it’s absolutely necessary for you to help them flesh out more detailed requirements in the planning phase – but when they come to the project with nothing it’s time to put on the brakes.

#2 - A group of subject matter experts (SMEs)

During the engagement you’re going to need access to some end users and subject matter experts because there will be questions you’ll have for them as you try to piece together the requirements you’re working with. These people need to be identified up front and need to be prepared to be adhoc members of the customer’s project team.

#3 - An assembled core project team

If you’re dealing solely with the project stakeholder at the kickoff meeting, then you’re customer may be unprepared. They need a core team of their own to assist you and your team in putting more detail into the project, identifying issues and risks, and verifying the project schedule that you’re proposing.

#4 - Preferably a project manager or point person

Again, dealing with a stakeholder is great and that person may, indeed, be the project manager. But if not, there needs to be a primary counterpart on the customer’s side to you as the project manager. Someone you can go to to get things done on their side. Someone to enforce accountability and direct activity because there will be customer assignments.

#5 - Training or software knowledge (if applicable)

This is a tough one and the customer may push back, but if you’re dealing with a software or IT project, then in order for you and your team to get the best possible requirements documented, your customer must have an understanding of what you’re implementing. If they don’t understand the capabilities at all, then they can’t truly fully understand how much or exactly what the solution will be able to do for them. Basic training is a huge plus to the project.

How do you know they’re ready?

So, I’ve presented a list – and I would welcome any comments or additions that any of our readers might have. This list is based solely on some of the frustrations I’ve encountered on the many projects I’ve led over the years. I’m constantly surprised by how unprepared some customers are when they come to a kickoff meeting.

How doe we figure out if this customer is ready or not? It may become evident as you start to go through the statement of work (SOW) because most of the project goals and assumptions are listed there. If the SOW discussion surprises your customer and they seem uncertain of what’s expected of them, it may be time to slow things down. If you are implementing a software solution and the customer has no knowledge whatsoever of its capabilities, then there’s no way they’re really going to be ready to discuss detailed needs and requirements. You likely need to offer training. Ask about their project team because you’re going to need that information for assignments in the project schedule. If they don’t have a team, then you may want to give them a week to put the proper team together. Discuss the project schedule that you’ve drafted. If there are any major sticking points with the customer, then halt the kickoff and get those ironed out before proceeding with the engagement. The worst thing you can do is start the project before both parties are prepared to start because you’re going to find yourself behind schedule very quickly as you work with your customer to identify and fix these weaknesses.

Brought to you by www.project-drive.net.

Friday, December 9, 2011

When Your Project Depends on Other Projects that are Struggling

Managing a project to a successful end is hard enough as it is. Most of the time your project is a one-time effort and it is completely standalone – other than the fact that it likely integrates with some existing technology and business practices. Those, of course, become integration points and separate tasks in the schedule as well as areas of testing concern and highlights as the project moves on towards deployment.

Now consider the scenario where your project depends on the outcome or progress of one or more other projects. Projects that you likely aren’t even leading, but must be involved with to some degree to ensure proper testing, handoff of information, timing of training and deployment, and to ensure that any solution integrations are properly aligned. If those other projects are running smoothly, then you have no issues. However, if there is a delay or an issue with one of the other projects – and most projects do experience delays and issues along the way – what do you do? How do you handle it? How does it affect your project?

In the few cases where this has either been an issue for me or appeared that it would be, these are the steps I setup to get corrective action rolling…

Discuss with the customer

As this has always been the case with interrelated projects for the same customer, that customer is an integral part of the team on each project and a key decision point for any action going forward. If that customer is not already aware of the impending critical problem, then you – and the other project manager if the struggling project is not also yours – must sit down with the customer and relay the issue to them. Keeping a significant problem from the customer will only delay the inevitable and can serve to cause trust issues should the customer discover the problem before it comes from your mouth.

Brainstorm with the other project managers and teams

You and your team must then work cohesively with the project manager and team on the struggling project to determine what their issue is, how quickly it can be resolved, what impact it has on their schedule, and then what the overall impact on your project and schedule is or will be.

Develop an action plan

Next, set about documenting possible action plan scenarios. Will more or different resources on the struggling project help solve the issue? Will more money do it? Are the struggles due to issues at the customer level? Do some requirements need to be further defined and if so, what re-work might be involved.

Once this is determined then – and only then – can you figure out the best and most cost-effective and least detrimental course of action to recommend to your leadership and to the project customer.

Circle back with the customer

Finally, return to the customer with the proposed course of action. Clearly detail to them how the struggling project is going to get back on track – and this should be presented by that project manager if it is not already your project. Then present the impact to your project – the one that was running smoothly till the issue arose – and show them a new project schedule with these effects built into the scenario. If there are any avenues for regaining lost ground on the timeline due to the issues forced on your project, outline those actions as new tasks in the project schedule and discuss those in detail with your customer.

One final step – don’t forget to get signoff/approval from your customer on the overall course or courses of action you plan to take. It may seem like a small technicality, but it can become a very valuable signoff should there be any legal concerns at the end of the engagement.

Brought to you by www.project-drive.net.