Detailing the Project Management Audit Process

Diving a little deeper PM audit process as described in the book “Information Technology Control and Audit”, we will look at the audit planning, the actual PM process review, the act of working with the PM and team to identify risk, and the communications necessary to ensure that the audit process is as successful as possible.

Audit Plan

The audit plan will detail the objectives and the steps to fulfill the audit objectives. As in any audit, a project management audit will begin with a preliminary analysis of the control environment by reviewing existing standards and procedures. During the audit, these standards and procedures should be assessed for completeness and operational efficiency. The preliminary survey should identify the organization’s strategy and the responsibilities for managing and controlling development.

Project Management Process Review

A project management process review would assess the adequacy of the control environment for managing projects. The review points listed represent checkpoints in the project management process. Auditors can use these checkpoints to determine both the status of the project’s internal control system and the status of the development project itself. These reviews eliminate the necessity of devoting large amounts of audit resources to the development effort. As long as the development process is well controlled, the need for audit involvement is minimized.

Project Management

Auditors may assist the project manager in identifying project risks and evaluating plans to mitigate and manage risks (e.g., training, devoted resources, management support, and end-user commitment). Auditing can provide management with an independent review of project deliverables (e.g., project charter, task list, schedule, budget). Auditing may also review the project task list and budget to verify that all project tasks are defined and all milestones have a deliverable.

During the planning phase the auditor can facilitate communication between functions and raise issues that may impact the quality or timeliness of the project. In a development project, resources from various departments need to come together to implement an automated process that may affect multiple user functions. Because of various audit projects, auditors develop an overall knowledge of the organization and establish relationships in multiple departments. These relationships are helpful in a development project for making sure information is flowing between the development team and other functionaries. Consider the following groups:

• Primary users
• Secondary users
• Vendors and consultants
• Programmers and analysts
• Database administrators
• Testing teams
• Computer operations
• Interfacing systems
• Implementation team
• Production support (i.e., maintenance programmers)

Verify that adequate resources are assigned responsibility for tasks and have the time to complete assignments. This includes development, computer operations, user, and support functions (e.g., help desk).

Communication

The first area to communicate is the auditor’s role in the systems development project. It is very important to make sure that the management and development teams’ expectations of the auditor’s role are understood and communicated to all participants. In order to influence the systems development effort, the auditor must develop an open line of communication with both management and users. If a good relationship between these groups does not exist, information might be withheld from the auditor. This type of situation could prevent the auditor from doing the best job possible. In addition, the auditor must develop a good working relationship with the manager, the analysts, and the programmers. Although the auditor should cultivate good working relationships with all groups that have design responsibilities, he or she must remain independent.

Recommendations

Throughout the development project, the auditor will be making control recommendations. Depending on the organization’s culture, these recommendations may need to be handled informally by reviewing designs with the project team or formally by presenting recommendations to the steering committee. In either case, the auditor must always consider the value of the control recommendation versus the cost of implementing the control. Also, recommendations should be speci?c, identifying the problem and not the symptom. This allows the proper controls to be implemented and tested.

Recommendations are often rejected because of a time and cost factor. Managers may sometimes feel that implementing an auditor’s recommendations will put them behind schedule. The auditor must convince management that if the recommendations are not implemented, more time and money will be spent in the long run. Informing management of the cost of implementing a control now rather than shutting down the system later to repair it or leaving possible exposures open will help convince management of the need to spend time and money now.

PM Best Practices for the New Project Manager

PM Tips is designed to be a discussion area and information source for both the experienced project manager and project managers with little to no experience. For PMs with a significant amount of experience, many of the things that are generally considered ‘best practices’ are things, hopefully, that we do without even thinking.

For the new PM, however, these concepts can not be taken lightly as they may not be intuitive yet and newer PMs may even be working in an organization that provides little to no support for the PM process. In some smaller organizations or companies where IT is a sidebar rather than a primary focus, the newly anointed PM may be standing alone trying to get their arms around a portfolio of ‘projects’ in various stages of disarray.

How do you jump in and take over managing in this type of situation. I’d like to discuss that at length and share my thoughts, but that’s probably for another article. Here, I’d like to discuss some of the ‘best practices’ that the new PM should employ as basics to getting started on the road to good, solid, project management performance. Paying close attention to these 5 key areas will help the project manager stay on track toward a successful project conclusion. The degree of effort that is put into any of these areas depends on the size, timeframe and budget for the project, but they all must be performed.

Scope Management

Get a good handle early on as to the proposed scope of the project that you’ve been handed. Gather as much info concerning the scope from whoever closed the deal and handed you the project. Jot down any project requirements you don’t fully understand and be sure to discuss those in detail with your customer before or during the kickoff meeting. This proposed scope is critical because it is the basis for the project, the input for the project schedule and ultimately what your project will be judged against.

Reporting

A good rule for the PM, at a minimum, is to provide your team and your customer with the following, in terms of project reporting on a regular basis:

• Weekly project status report
• Weekly budget status/forecast update (if applicable – discuss with your customer early on)
• Weekly revised project schedule

The project status report will be the document that drives the weekly status call with the customer and the weekly revised project schedule will be what shows the team and the customer whether or not the project is on track and will let each team member what their responsibilities are for the week and for the rest of the project.

Budget Management

It’s imperative that the PM management the budget and the forecast (both financial and resource) very closely. Whether that gets shared with the customer regularly may be a matter of corporate policy or may be based on your customer’s preferences. But at the very least, the PM must be on top of this at all times.

Losing control of the budget and the forecast – which can be relatively easy to do – can cause major problems down the road as the project nears completion. Finding out in the late stages that you’ve run out of money is hard news and sharing it with your customer as a ‘surprise’ will not only result in great customer dissatisfaction, it may either get you pulled from the project or it may get the project canceled on the spot. Both are bad for your career.

Timeline Management

The project schedule is what lays out the entire timeline for the project identifying key deliverables and milestones. As mentioned in Reporting above, the project schedule is a critical piece of information for each project team member and must be revised and distributed weekly to everyone.

I’ve not managed a project yet where the original project schedule remained unchanged throughout and I just managed from it. Because of change orders, issues, customer preferences, or revolving project resources, there are monthly, weekly and sometimes daily changes to the project schedule. Those must be accurately noted and distributed to the team and the customer on at least a weekly basis.

Customer Communication

As the Project Manager, how and what you communicate to the customer will go a long way in determining customer satisfaction on the projects you manage. Keep them engaged in all critical project communication. Don’t keep the bad news from them…but don’t tell them the sky is falling all the time either. If you have bad news to share, be well prepared to deliver it. In fact, it’s best if you already have a planned course of corrective action. But if not, share it with the customer and ask them to share in the corrective action. It’s their project, too…and they want you to succeed.

Closing Out the Project – Part 1

When you’ve reached the end and deployed the solution, then it’s time to make sure everything has been completed, all paperwork is done, and no stones are left unturned. It’s best to do that with some sort of checklist and I propose using a list similar to this:

• 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?

In Part 1, we’ll discuss the first three items above:

• Have all the project objectives been achieved?
• Is the client satisfied with the overall project?
• Have the necessary post-project support agreements been established?

Have all the project objectives been achieved?

This should be fairly easy to evaluate. Look at the project schedule and review all milestones and deliverables. Have they been met? At this point, we’re not considering timeliness or budget, we’re just concerned with did we hand the customer what we said we would. Did we supply a Functional Design Document, did we provide weekly status reports, was training completed successfully and signed off, was user acceptance testing (UAT) fully completed including re-review of all issues and did we get official signoff, etc.

Though it definitely shouldn’t be the first time during the engagement that you do this – it’s also a very good time to go back to your kickoff session notes and see that all points discussed during that meeting have been addressed. Make sure at this point that the customer knows you’re concerned that you fully covered everything for the project – they’ll appreciate it and it definitely helps with customer satisfaction levels and can increase the chances of repeat business from this customer.

Is the client satisfied with the overall project?

You may think you can simply answer this yes or no based on your knowledge of how things went on the project and the communications you had with the customer along the way – but that is not always the case. On some projects, you can end up being very surprised by the customer’s on viewpoint of their satisfaction levels.

I’ve had customers on projects that went extremely smoothly later state that they weren’t happy about how I handled something or weren’t pleased with one of my team members or how we delivered ‘x’ deliverable. And I’ve had other projects were I was certain the customer was just about ready to ask that I leave the project only to find out that they were very happy with me and with the team and how things were going. They were just demanding and somewhat needed. But we were meeting their needs and they were happy. It’s amazing how off your perception can sometimes be concerning your perception of the customer’s satisfaction level and what their satisfaction level truly is.

Have the necessary post-project support agreements been established?

Usually you’ll move from deployment into a post-deployment with some sort of pre-defined plan to both hand-off overall support to your tech support group but also you’ll agree to make your original delivery team available for a 30 or 60-day window to do immediate fixes should problems arise in the functionality of the delivered solution. That’s something that just needs to be worked out with the customer and something that was likely planned for both by Sales with the customer during the sales process and discussed between you and the customer during kickoff.

Just make sure that whatever the plan is, you act on it. If it’s to keep your team available for 60 days should problems arise, then make sure that every team member knows that and that each of their managers know that as well. It can have an affect on their next assignments, but it must be addressed in advance of deployment.

Next

In Part 2 we’ll further discuss these items in terms of the project closeout checklist/review…

• What were the major concerns with the project?
• What are the key lessons learned from the IT project?
• What would you do differently?

Attributes of a Successful Project Manager – Part 2

In Part 2 of this three-part series we will look at further at Jason Chravat’s presentation of the attributes of a project manager from his book entitled “Project Management Nation: Tools, Techniques, and Goals for the New and Practicing IT Project Manager.”

In this segment, we’ll discuss the need for the project manager to have:

• General knowledge of project management
• Understanding of technology and some technical background
• Ability to work successfully as a problem resolution professional

These are just a few more of the key areas of expertise that the project manager needs to possess. Read on for further discussion.

Knowledge of Project Management

The first step for a newcomer to become qualified in project management is to complete a program of education. Meeting with others who are learning about project management is helpful, but it takes time. Alternatively, a prospective project manager can gather the information on his or her own. Those new to the profession don’t always need degree programs or pay large sums of money just to learn project management. Many of the world’s leading project managers learned their skills and techniques from experience and on-the-job training. That’s where the best secrets lie, and that’s why I thought sharing my experiences with project management would be helpful.

Technical Authority

Project managers often tell me that, as project managers, they do not need to understand the technology or technical issues because the technical resources working on the project will be responsible for the technical detail. Unfortunately, in the IT environment today, it is important for all project managers to be well-versed in the relevant project technology (including its applications and processes) and be able to communicate on technical issues with the “techies.” The majority of organizations that employ project managers insist that the project managers be able to take technical decisions and that they possess the necessary technical skill sets to be on a similar level as the technical staff.

I have heard many IT resources complain bitterly about project managers who haven’t got the foggiest notion of what needs to be done technically. The result is often that many of these resources simply carry on with their own development process and view the project manager only as an administrative manager who coordinates time sheets and ensures the delivery of status reports.

Project managers who are not well versed on the technical level find themselves (1) isolated, (2) lacking in credibility, (3) not consulted technically on major development issues, (4) not taken seriously, and (5) possibly even provided with false information. Project managers who understand the technology and can use it practically can apply such knowledge with outstanding results. Project managers also need to be certain that they have obtained the necessary project authority from the project sponsor and then communicate this to all stakeholders. This senior executive involvement often does the trick!

I always encourage project managers to make technical decisions if and when an opportunity arises, or to be involved in any way possible, by playing the role of facilitator or negotiator with the staff.

Sun Tsu said…

If the general’s employment of his mind is not in harmony with the army, even though the formation’s lightness and heaviness are correct, and the front and rear are appropriate, they will still not conquer the enemy.

Ability to Identify and Resolve Problems

Problems will arise on any project, no matter how much planning and effort have been made to avoid them. Recovering from any such problem means that the earlier the project manager can address the problems, the better. Identifying problems may require the project manager to review tasks with resources in order to find the real causes of these problems. If the causes are not within the manager’s own control or authority, then he or she must go to the project sponsor and seek advice there.

As alarming as this may seem, it may mean stopping the project until a solution is found, which is a good suggestion. Remember, the earlier you make the input to correct things, the smaller the input required.

Continuing to let tasks and milestones go off track will make it more difficult to correct the situation.

In Part 3, we’ll look at the project manager’s need for an ability to make timely and critical decisions, effectively select and manage a team of skilled resources, and to have a professional approach when dealing with management, teams, and the customer.

Project Readiness: Ten Things You Must Do Before You Start

You’re handed a critical project to take and make your own. You finally get to go cradle to grave on it – you’re not just taking on someone else’s mistakes this time. What do you do to get started? Here’s a list of ten must-do’s – in no particular order – that will help ensure that you get the project off on the right foot.

1. Review the Statement of Work (SOW) – This is your starting point and the main document for the project to take off from. It’s loaded with assumptions, expectations, deliverables, milestones, rates, sometimes estimates, etc. It’s your starting point for putting together a decent draft project schedule, draft budget and forecast, and definitely the basis of most of the information you’ll want to cover in a kickoff session with the customer.

1. Identify the necessary resource skill sets for the project and request them – As early on as possible, identify what skills you’ll need for the project. Other projects and other project managers are likely in need of some of the same skilled resources and they’re usually in short supply, so put in formal requests as soon as possible. Don’t request them too early, because engaging a resource before it’s needed can blow your budget out of the water. The challenge is to onboard the necessary resources at just the right time so they’re fully and efficiently utilized.

1. Draft a project schedule – Sales may have provided you with a draft schedule that they worked out with the customer during the sales process. If they did, that may be a good starting point…depends on how competent and technically inclined your sales group is. If not, then start with the SOW and start plugging in timeframes, deliverables and key milestone dates noted in the document. Even if you do get a draft schedule from Sales, always cross check it with this document….ownership of the schedule is yours, not theirs.

1. Hold a knowledge transfer call with Sales – Conduct a call with the sales person or account manager that worked closely with the client to close the deal. They likely put together some of the SOW, drafted a schedule and rough budget and can give you insight on the customer and their key contacts. Those key contacts will likely be part of your customer team so any info you can get before going into the engagement puts you that far ahead to begin with.

1. Call the customer and introduce yourself – Before any formal face-to-face or project kickoff meeting, call the may contact or contacts and introduce yourself. You can maybe even think of a couple of high-level questions to ask them, but save the detailed questions and information for a later face-to-face meeting. This informal introduction call is not the time for that detail.

1. Do an initial forecast of resources for the length of the project – Depending on what kind of information is contained in the SOW, this may be a relatively easy task. Sales had to work out some detail in order to come up with a price for the customer. That’s your budget and it’s likely derived from estimated hours for each planned resource with prices attached to each. If that’s the case, then you’ve got a great start for a budget and forecast for the duration of the project. You’ll have to make calls based on deliverables and milestones on when to engage the resources and for how long, but you can cross check them with the estimated hours from Sales. This will be the basis for the budget and forecast that you’ll manage and share with both teams for the rest of the project.

1. Comprise a list of detailed questions for the customer – Following an initial call with the customer, discussions with Sales, and a review of the SOW, you’ll have some questions that need answers. These will be things you’ll need to know for input into the detailed schedule and how the customer may want certain things run on the project. Getting answers to these questions will help you put together information for your first detailed meeting with the customer which will likely be a formal project kickoff session.

1. Put together a first status report from what you know so far – Taking what you’ve learned so far from discussions and SOW reviews, you can put together your first status report for the customer and deliver it before the kickoff session. Include what you have so far for the draft schedule, budget and forecast. It will go a long ways in building initial confidence in you in the customer’s eyes because it will show that you’re in control and on top of things.

1. Put together a kickoff packet and schedule a face to face with the customer – Using something like PowerPoint, put together a formal presentation that you’ll use in the face-to-face kickoff session. Work with the customer to schedule a day-long session (or however long it needs to be based on your project’s needs) and make sure they have the right people attending (but not too many!). Explain to them that too many attendees lead to too many questions and eventually a kickoff meeting that is derailed and non-productive.

1. Conduct the kickoff session – Hold the formal kickoff session with the customer. Review the SOW, proposed team roles on both sides, deliverables, milestone dates, how and when meetings will be conducted, and discuss the change order process. Refrain from discussing budget items in this meeting unless the customer requests it – I’ve usually had the experience that customers only want certain people on their side privy to budget info.