Doing the Right Things for Your Customer

Customers are a demanding group … that’s a given. When we have all of our regular project responsibilities to deal with on a daily and weekly basis, how do we know when we’re doing the right things for our customers? How do we know we’re managing them well, responding to the right requests, saying ‘yes’ when we should and saying ‘no’ when we should, and ensuring that our actions are not detrimental to the forward progress of our project?

You can’t always base it on customer satisfaction levels. Because attentive ‘do-anything-for-the-customer’ behavior may get a project manager and team high marks mid-way through a project. But upon implementation, if they’ve said yes to too many things that ended up modifying scope and delivering a system to the customer that is ultimately not what they ordered, then that customer satisfaction at the end of the project will be low. The end user community will have a product that they didn’t sign up for and that’s a very bad thing.

In order to ensure we’re doing right by our customers, we first need to have confidence in what we’re doing. And we need to have confidence that we’re doing the right things for the project. We can do that in a few ways, including:

Read more »

Onboarding with Success

When you’re asked to jump on a new project how do you go about doing that to ensure your best chance for success? That may often depend on why you’re being asked to take over the project … and it can be for any one of the following reasons:

• Previous project manager failed to manage the team and project effectively
• Previous project manager lost the customer’s confidence
• Previous project manager lacked the expertise to lead the project based on new direction
• An emergency necessitated an early departure for the project manager
• Co-management became a necessity due to changes on the project Read more »

A Lessons Learned Template

Lessons Learned – often talked about, a discussion that is usually planned…but often forgotten.  You’re at the end of the project and the plan is to pull both teams together to go over lessons learned in great detail and for the benefit of all – but it often doesn’t happen.  Team members move on to other projects or post-deployment issues are taking up everyone’s time.

Lessons Learned sessions can be very helpful – and if you’re luck enough to keep yours on the project schedule, then this template may help you.  It looks a little rough pasted into this post and one of the tables turned into a bullet list, but I think you’ll get the idea.

As always, if you want the Word doc template, let me know…and please feel free to share your version as well.

PROJECT LESSONS-LEARNED DOCUMENT

The purpose of this template is to help the project team share knowledge gained from experience so that the entire organization may benefit. A successful Lessons-Learned program will help project teams:

• Repeat desirable outcomes
• Avoid undesirable outcomes.

A. Your project team should begin to use this document at its first project meeting. Continually recording Lessons-Learned throughout the project is the best way to ensure that they are accurately recorded. Topics to consider include all of the following (feel free to change the list). The Lessons Learned Checklist is also available as a guide to discussion.

B. At the end of your project, use this document to summarize your experience.

During your discussions:

• Be positive
• Do not place blame!
• Focus on successes as well as failures
• Indicate which strategies contributed to success
• Indicate which improvement strategies would have the greatest impact

The signatures above indicate an understanding of the purpose and content of this document by those signing it. By signing this document, they agree to this as the formal Project Lessons-Learned Document.

How to Make Project Management Work in Your Company

I ran across the list below – which is actually a subset of the original list – while reviewing the book “The Fundamentals of Project Management” by James P. Lewis. This book was published in 1995 so thoughts and processes have changed a little. I’ve selected what I believe are the most relevant items from Mr. Lewis’ original list for inclusion in this article. I’ve made some changes and additions as well. Read on…

It is one thing to know how to manage projects effectively. It is another to get people actually to manage them that way. Running by the seat of the pants seems a lot easier than doing all that planning, scheduling, and monitoring. Even when people invest three or four days in project management seminars, you find that they soon forget what they have been taught and go back to the old ways.

I have struggled with this problem for over fifteen years, and I finally have some answers. Here are suggestions on how to make the principles of project management work in your company.

• Get top management involved in the process and the projects. They should be asking questions about how projects are doing. In other words, show an interest in the subject.
• Build into performance appraisals items that evaluate a project manager’s use of the tools of effective project management. Reward people for practicing the methods. But be careful. Be sure upper management is not keeping managers from practicing good methodology.
• It helps to have the entire team trained in project management basics.
• Senior management need to understand the company’s PM process and methodology to effectively set their expectations. One of the ten most common causes of project failures is unrealistic expectations on the part of senior managers.
• Practice a lot of MBWA (management by walking around – or at least very frequent communication) as the project progresses, but do it to be helpful, not in the blame-and-punishment mode. Give people strokes for letting you know about problems early, rather than after they have turned into disasters. Don’t be too quick to help, though. Give people time to solve the problems themselves. Just ask them to keep you informed, and tell them to let you know if they need help. Be a resource, not a policeman.
• Do audits to learn, and try to improve whenever possible. Verify that processes are being followed, status reports are being produced, customers are getting the info they are supposed to get, and project plans are being updated regularly. Make sure the processes that are in place are being followed.
• If you find you have a problem individual on your team, deal with that person as soon as possible. Don’t ignore the problem, as it can wreck your entire team.
• Be very pro-active, not reactive. Take the lead. Break roadblocks for your team members. Go to bat for them.
• Have team members make presentations to senior management on their part of the job or periodic presentations on their key projects. Give them credit for their contributions. Build ownership.
• If you are running a project to which people are temporarily assigned while still reporting to their own bosses (matrix organization), keep their managers informed about what they are doing. Try to build good relations with those managers. You may need their support to get the job done.
• You may find that you have to co-locate the people doing activities on the project’s critical path so that you don’t have them constantly pulled off to do other jobs. This method is being used more and more by major corporations for highly critical projects.
• It is also possible to appoint a project administrator to either do the project support or delegate it and to sit in on project review meetings and hold the team’s hands to walk members through planning, audits, and so forth. Naturally, you need to be running quite a few projects (at least ten to twenty) to justify creating this position, so this depends on the size of your organization.
• Benchmark other companies to find out what they do with project management.
• Have individuals take responsibility for championing various parts of the project management process. One person, for example, the earned-value champion, might go around the company trying to get everyone to use the method. Another might take responsibility for dealing with WBS notation, and so on.
• Read PM Tips and follow everything on here! (ok, just kidding, I added this one….)
• Look at managing projects as a challenge – keep it exciting. Stick to a process, but change things as needed to accommodate the project and the customer.

The IT Auditor’s Role in Project Management Process

In larger organizations or on larger government projects, it may be recommended and even required to conduct audits of the project management processes being utilized in an organization. It may even be necessary to audit individual projects for process adherence.

I have personally been involved in many large government projects and programs that required detailed auditing and the presentation of audit findings to the proper government officials. With the help of the book “Information Technology Control and Audit” (by various authors) I’d like to discuss how this IT audit process might oversee and substantiate the project management process utilized for a given project and for the portfolio of projects your organization is undertaking.

Auditing the Project Management Process

The auditor’s role in project management depends on the organization’s culture, maturity of the information systems function, and philosophy of the auditing department. The objective of a project management audit is to provide an early identification of those issues that may hinder an on-time, within-budget implementation of an application that is controlled, documented, and able to be operated by an adequately trained user community. Auditing project management requires specific knowledge about the project management life cycle and development process. Understanding these allows the auditor to identify key areas that would benefit from independent verification. The scope of a project management audit can include an evaluation of the administrative controls over the project (e.g., feasibility results, staffing, budgeting, assignment of responsibilities, project plans, status reports, etc.) or an evaluation of specific deliverables to validate that the project is following established standards.

By becoming involved at strategic points, the auditor can ensure a project that is well controlled. The following list highlights some of the key tasks the auditor may perform during a project’s development:

• Gain the support and cooperation of the users and IT professionals.
• Check project management tools for proper usage.
• Perform project reviews at the end of each phase.
• Assess readiness for implementation.
• Present findings to management.
• Maintain independence in order to remain objective.

These tasks can help provide early warning of project management issues.

To determine the level of involvement, the auditor should first complete a risk assessment of the project development process and determine the amount of time to be allocated to a particular project. Next, the auditor should develop an audit plan that includes a schedule for the specific review points tied to the project schedule. Finally, the auditor needs to communicate the scope of involvement and any findings to the project manager, users, and IT management. During the early phases, auditors do not determine how controls will be implemented, but they should establish the review points. This helps IT personnel to better understand audit objectives.

In the coming articles, we will look at each of these processes that the auditor must go through when evaluating project management oversight on a project.