Establishing Objects and Gaining Conceptual Agreement with the Client

I’m taking a little turn from purely project management concepts and thinking more in terms of the IT Consultant in general. Afterall, many of us working as project managers are at any given time part of a professional services organization that thinks of us basically as consultants to THEIR clients.

Establishing objectives is the starting point of any consulting project. It’s impossible to do anything else until and unless you know the desired ending point. Below are some specific questions to discuss with the client in order to elicit some outcome-based business objectives. Take them with you whenever you sit down with a client or potential client as you work through that initial meeting both selling your services and diving deeper into their need and expected results.

• How would conditions ideally improve as a result of this project?
• Ideally, what would you (the client) like to accomplish?
• What would be the difference in the organization if the project is successful?
• How would your customer (the client’s customer) be better served by this project?
• What is the impact you seek on return on investment/equity/sales/assets?
• What is the impact you seek on shareholder value?
• What is the market share/profitability/productivity improvement expected?
• How will you (the client) be evaluated in terms of the results of the project?
• How would your (the client’s) boss recognize the improvement?
• How would employees notice the difference?
• What precise aspects are most troubling to you – what keeps you up at night?
• What are the top three priorities to be accomplished?

In establishing conceptual agreement about the objectives of the project you are about to undertake together, you – as the consultant – are trying to ensure the following:

• The client is not expecting anything that you cannot deliver to them.
• The client is not expecting anything that is unreasonable under the circumstances and is not within the culture and environment that the project will be performed in.
• There will be no misunderstanding later about why additional work wasn’t performed. The limits and goals of the project will be understood and agreed upon.
• The client is maximizing your contribution and talents on the project so that the project is as effective as possible for the client and as lucrative as possible for you.

If you begin with carefully constructed objectives, you can then create a framework within which the project can be launched. From that, the project can progress toward the agreed upon goals and final solution and draw to a close. Boundaries can be derived from clear objectives. While it seems that a never-ending project is lucrative for you, it actually is not. If the end is never reached, then success is possibly never really understood and realized. Setting clear goals and reaching them is what leads to future work with the same client, not a seemingly ongoing project that drains their financial resources.

More on Lessons Learned

It is my belief from my years of project management that performing a lessons learned activity is one of the most critical processes for future project success and yet also one of the most overlooked and underutilized. We tend to get to the end of a project and breathe a sigh of relief and move on. Rather, we should hold one or more formal sessions with our team and our customer to identify what worked and what didn’t.

The customer always has a lot to say about any implementation and their opinion and input matters greatly. It’s best for you to hear it in a formal lessons learned process rather than have your customer follow-up with your CEO and give him an earful.

I’ve published some of my thoughts on Lessons Learned previously including an article from February 2009 titled simply “Lessons Learned.” Here, I present some further thoughts on lessons during the project implementation process from Jason Charvat’s book “Project Management Nation.”

Lesson Learned During Project Implementation

“What could be simpler than buying some computers, throwing them on a desktop, plugging them in and turning them on?”

The question is simple: The answer is much more complex. Complexity is almost always underestimated until well after the start of the planning process. Many of the elements of deployment require special coordination and handling due to the lack of direct control over the processes or compounding dependencies. Complexity can come from the technical nature of a project that attempts to take advantage of a new technology not yet tested by the corporation and requires full integration into the existing systems. These factors don’t surface until the project manager demands action or some form of change. Implementing a solution without testing it properly is not acceptable.

I Wish I Had Known That

Look for early warning signs that planned business benefits will not be delivered.

• It is not clear that achieving the business benefits is the top priority of those managing the project.
• Time scales and resources for training, testing, and implementation support have been eroded by project slippage, and there are proposals to cut corners.
• Acceptance testing is being carried out by IS specialists and there is no involvement from the business.
• Other parties, who were not previously identified as part of the project, are now being identified as needing to be involved in acceptance testing and implementation.
• Staff involved in developing and agreeing to the original business objectives have moved on.
• The supplier has not demonstrated that the new system is compatible with existing systems and peripherals.
• The solution needs to be tested and demonstrated within the proposed environment (including links to existing systems). Have the tests for accepting the system from the supplier been planned and agreed upon? Has the process for data conversion been planned and has sufficient time been allowed for it?
• All necessary on-site preparations were not included in the planning (e.g., accommodation, cabling, safety, and security).
• All dependencies, such as slippage on other related projects, have not been taken into account.
• Too little attention is paid to testing the final solution.

Closing Out the Project – Part 3

In Part 1 and Part 2, we covered the first six critical questions listed below that should be addressed when closing out any project. In the finale, Part 3, we’ll cover items seven through nine highlighted in bold letters below:

• Have all the project objectives been achieved?
• Is the client satisfied with the overall project?
• Have the necessary post-project support agreements been established?
• What were the major concerns with the project?
• What are the key lessons learned from the IT project?
• What would you do differently?
• Do you feel the solution was cost effective?
• When would it be applicable to enhance or update the delivered solution?
• What is your executive leaderships view of the project outcome?

Do you feel the solution was cost effective?

Here’s your chance to analyze the solution in words in financial terms. And we’re not really talking about budget here, but that’s a big part of it. In hindsight, did the engagement:

• Utilize the best level of resource skills and thus use resources in the most cost effective-way possible.
• Should Phase A really have been implemented first as the customer required, or would it have been a more sound business decision, in your opinion, to implement Phase B first?
• Is the final solution meeting the customer’s needs in the most cost effective manner possible? Would certain enhancements or different requirements have resulted in a more cost effective solution?

The list could be long, but I think you get the picture. Ask yourself the tough questions and imagine this isn’t for the customer to see. In fact, imagine you ARE the customer on this one but also have your additional insight.

I’m not saying you can’t involve the customer on this one – you certainly can – or you can perform it separately with your team and then with the customer and compare results.

When would it be applicable to enhance or update the delivered solution?

You’ve probably had an eye to the future all along and you’ve probably already discussed some key points along the way with the customer – especially if the project was a successful one and the customer satisfaction seems high. That’s what a good project manager does.

Think about ways you can provide new and future services to this customer and certainly keep in contact with them post-implementation on future product capabilities that you feel they will want or can benefit from.

What is your executive leaderships view of the project outcome?

This one is important to your career. No question about it. How does your leadership feel about the project? This likely will come more from leadership’s discussions with the customer than from your discussions with the leadership. And it should.

If it was a visible, critical project, you know that they’ve been in communication with the client along the way and if anything has gone wrong, they’ve heard about it. They’re not as likely to hear about the successes, but if you think the project has gone well, encourage your CEO or other leadership to follow-up with the client and discuss the outcome with them.

Summary

We’ve covered what I consider to be nine key questions to review once your project has been implemented. Most are for you and your team, some should also include the customer. But be sure to perform some sort of post-implementation checklist like this. You’ll benefit from it as a project manager, your team will benefit from it in learning what went right and what went wrong, and your organization will benefit from it – especially if you can share the successes and the lessons learned with others in the organization.

If you have other key points or questions to add, please comment.

Project Success Series: Delivering a Workable Solution

We are now ready for the final article – at least for now – in my Project Success Series. As with any blog, I reserve the right to come up with new content to add to any series like this so consider yourselves forewarned.

To recap, the premise here is that there are four main questions that your company CEO could ask you concerning whatever highly visible or mission critical project you are currently managing or just completed if you were to run into him in the hallway. Understandably, since this is your CEO, it is best for your career if you can be ready with meaningful and accurate answers to these questions and the proof to back them up. These questions are:

• Was the project on budget?
• Was the project on time?
• Was the customer satisfied?
• Did the project deliver a usable solution?

Part 1 dealt with the question concerning whether or not your project was on budget. In Part 2, we dealt with keeping your project delivery schedule on track. Part 3 dealt with the concept of customer satisfaction.

Now in Part 4 we will cover the concept of delivering a workable solution to the customer. And not just one that is bug-free, but a solution that the customer wants and needs and it’s your job to deliver that even though we all know that the customer often isn’t truly aware of what it is they actually need. Frustrating? Yes! Let’s discuss ways we can ensure that we’re delivering the best possible solution for the customer.

Never Assume the Customer Knows What They Want

I’ve covered this one elsewhere, but it’s an easy trap to fall in to. After all, they’re the customer and all we have to do is build to their requirements, right? Wrong! Be sure to ask the right questions up front and don’t be afraid to ask the customer to go back to their end users and SMEs and make sure that they understand what the final solution really needs to be. Many times though don’t truly know that when the engagement starts. If that is the case, one of two things happens:

• It becomes apparent part way through the engagement and then the customer is faced with change orders, a stretched out timeline, budget overruns due to re-work, and a lot of frustration for both teams.
• It doesn’t become apparent until deployment when the end user finally gets their hands on it and it’s not what everyone dreamed it would be. Sure, you built to the customer specs, but the lasting legacy is that the customer has an unusable solution and the finger often gets pointed at you and the delivery team.

Assemble a Skilled Delivery Team

As with any engagement, the more applicable skills your team has for delivering on the engagement, the better chance you have for success. With a good SOW and detailed requirements, you’ll know what skills you need. Fight for those with your management and work hard to keep that team engaged…meaning manage the schedule tightly, etc. Less ‘down’ time during the engagement means less likelihood you’ll lose skilled resources to other projects.

Don’t go overboard acquiring the best skill set in each area of need if that’s unnecessary because you’ll end up costing the project extra $$ that aren’t necessary. Protect profitability by going after the right skill level for the need and then work hard to manage the resources well and keep them engaged on your project.

Track Requirements As Though Your Life Depended On It

During Exploration and Design, map out the customer requirements well using a Requirements Traceability Matrix (we’ll cover that in another article) and manage those requirements closely. Keep track in the matrix of where those requirements are implemented in the final solution. Missed requirements mean a solution that doesn’t match your customers documented needs.

Test and Re-Test

This is an easy one. Have the customer build their own test cases and also use those during your own system tests prior to UAT along with your own test cases. Make sure the customer has solid, knowledgeable resources engaged for the User Acceptance Testing (UAT) sessions and definitely get their signoff on UAT once it’s completed.

A well-tested system goes along way in ensuring that the delivered system will work for the customer.

CYA – Get All Signoffs Just In Case

This one can’t guarantee that the customer is getting what they want, but it does help guarantee that even if they don’t, your butt is covered. Signoffs on requirements, UAT, and deployment go along way in removing blame from you if the shoe drops. Not that we ever want an unsatisfied customer. But the only thing we want less than an unsatisfied customer is an unsatisfied CEO or PMO Director who signs our paychecks. Get signoffs…you’ll sleep better at night…I promise.

This concludes my Project Success Series…at least for now. I’d appreciate hearing your comments and any additional areas that you think should be included.

When Project Management is Fun

Ok, “fun” may be a stretch…but not really. When do we dislike our jobs the most? When they are dead ends. When we’re micro-managed. When we don’t feel leadership is leading us. When we feel that we aren’t given the tools or authority to succeed.

I’ve had one or more positions where all of this happened….maybe not all in one job (though I can think of one specific job that encompassed most of these). I’m sure we all can think of a job where we were pushed down and we were unhappy. We tend to not be at our most productive selves in these types of jobs and under these types of conditions.

I’ve always found that I am at my most productive when the work is fun and when I have a great deal of control over that work. The same goes for the projects that I lead. If I have executive management that has a great deal of confidence in my skills and basically lets me run the show with the understanding I’ll shout out when there are needs as well as keeping them up-to-date on status, then I usually truly enjoy.

In fact, I find that managing projects with the some or all of the following 6 characteristics end up being the most “fun” for me to manage:

• Job Autonomy – This basically means being allowed a great degree of freedom and discretion in a job. When I’m allowed to lead a project and do the job well, make the right choices, and decisions and lead the customer without an excess of executive involvement, work is more fun, more productive and I can form a much better relationship with the customer.

• Focused Resources – Having skilled, focused resources that you know you can count on to get the job done certainly makes managing the project with confidence a lot easier. Knowing those resources are focused on your project tasks when they should be gives you the confidence to make appropriate promises to the customer and have your word stick.

• No Micro-Managing – Somewhat similar to Job Autonomy. I’m at my worst when I’m micro-managed and second-guessed. That’s for managers with nothing better to do. I once was leading a team onsite with a customer and had 5 other projects I was also leading. I was onsite with this team for 2 weeks – meaning I had 10 other weekly status meetings during those two weeks, 10 other status reports to delivery, 10 other project schedules to get out, etc. Unfortunately, I also had a senior manager there doing nothing more than walking around trying to make sure my team was focused on the onsite customer – I think because HE was being micro managed as well. It made it difficult to serve my other customers for this company with this individual constantly trying to get me back to focusing on the onsite customer – even though the technical resources on the project we engaged in the tasks we were actually there to perform (I was mainly there to just oversee that…which doesn’t require 24/7 oversight – and I could certainly afford 2-3 hours per day to devote to other projects).

• Requires Some Innovation – Leading a project that isn’t just a slam-dunk is more challenging to me and therefore more fun. One that requires more out of the box thinking definitely gets my attention – and usually challenges my team even more and keeps them excited and engaged.

• Cool Technology – We’ve all been here…any project that requires some cool technology makes the work more fun, right? What’s more fun…a project that requires an out of the box CRM system to be tested and implemented or a project that calls for a slot machine load testing simulator to be built from scratch, heavily tested, and implemented?

• Some Technical Hands-On – Coming from a technical background, I appreciate the chance to get my feet wet sometimes rather than just ‘manage’ resources and project deliverables. Even if it’s just cleansing and manipulating data and loading it into the final solution. Anything technically hands-on that changes the pace for me adds to the fun of managing a successful project.

Summary

There are projects out there that are cool and fun and cutting edge and there are others that are as dull as burnt toast. The best we can hope for is that we get a decent mix of both. We need some easy ones once in awhile – especially if our load is usually heavy. But the really challenging projects involving some and cool technology can help keep us fresh and having fun in our Project Management positions that, let’s face it, can be somewhat dry at times….at least that what my wife always imagines.