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.

Defining Risk Management – Part 9: Risk Control

This is the ninth and final installment in the Defining Risk Management series. In this final segment, we look at what risk control is and how we monitor and track the risks that are identified and new ones that are encountered on our projects. This information is again, for the most part, derived from the book “The Project Management Question and Answer Book.”

What is Risk Control?

The process of monitoring and controlling and keeping track of the identified and the unidentified risks is risk control. In this process we hope to identify risks that are no longer possible and risks that are coming due, as well as any new risks that may become evident. We will also monitor risk activity to make sure the risk plans have been carried out successfully. Problems that have been found out in the risk plan can help us adjust the plans for future risk activities.

Risk control and monitoring are part of the risk management process and must be started early in the project and continued until the end. As the project progresses, we will find that many of the risks will change, some will no longer be possible, others will happen and be disposed of, and new risks will be identified. In addition we will learn about the project and the risks associated with it and adjust our vision of individual risks.

The level of risk tolerance should be monitored as well. The attitude of the stakeholders will change during the course of the project. Communication with all stakeholders is important since it gives us a means of assessing changes in their risk tolerance.

Risk control may involve changing the way we look at risk. There are several reasons why this might take place. The risk tolerance of the stakeholders may change; the risk tolerance of the project team may change. As the project progresses toward its completion, certain risks that were thought to be very important to the success of the project may become risks that are no longer thought of as being so important.

In the beginning of the space shuttle project, the heat-resistant ceramic tiles were originally thought of as being one of the major risks in the program. If the tiles were lost or their integrity was compromised, the heat of reentry, some 3,000 degrees Fahrenheit, could reach the airframe’s aluminum structure and cause breakup of the ship. As time went by and NASA flew over one hundred missions with the space shuttle vehicles and the whole take-off and landing process became routine, the perceived severity of the risk diminished. During this time there were minor failures of the reentry tiles, but these failures proved to be minor repairs, and the shuttle vehicles suffered only minor damage. A program to develop a method of repairing risks in space was discontinued because it was deemed impractical. Part of the impracticality was probably because of the perceived reduction in the probability and impact of heat shield failures.

On February 1, 2003, just three days after the anniversary of the crash of the space shuttle Challenger, Columbia, the oldest space shuttle in the fleet, disintegrated on approach to landing. At this writing the investigations have hardly begun, but the heat shielding tiles are once again suspect because there is little that can go wrong on reentry except for a heat shield failure.

We see that during the project, the evaluation of the risk of heat shield failure began as a high risk. As time went on, the risk was revalued lower and lower. After the crash, the valuation of the risk has no doubt been raised higher than its former level.

In all projects, as we gain knowledge and experience about the project and its risks, we will change our attitude toward the risks in the project. This is natural and important. As we learn, we must change the level of effort we spend in certain areas or we will never have the resources, time, or money to complete any project.

A control system for risk is influenced by the organization the project is being managed under as well. In a project that is high in risk, we might have a person who is at a high level and is exclusively responsible for managing risks. On projects that are relatively routine by comparison, the risk manager may be the person responsible for the tasks that are most affected by the occurrence of a risk. These persons are responsible for communicating risk progress to the project manager and other affected stakeholders.

Risk audits can be used to document the effectiveness of the risk plans and the strategies that were used to mitigate, avoid, or transfer risks. A judgment can be made as to whether it was cost-effective to ignore the risks that were ignored.

Deviations in the project performance may indicate the effect of risks on the project. The earned value reporting system is helpful in identifying trends in performance on the project. Generally, schedule slippage and cost overruns are the result of some problems that have occurred. Trends in certain areas may indicate that risks are more severe than was anticipated or that new risks have taken place. One important product of the earned value reporting system is the indication of the cost and completion date at the end of the project. The sooner these slips in schedule or budget overruns can be communicated to the stakeholders, the better it will be for the project. Schedule slides and budget overruns that are severe enough can result in project termination.

A workaround is an unplanned response to a risk that was previously unidentified. These are the unknown risks that were discussed at the beginning of this chapter. They are also the risks that were passively accepted since these were deemed to be risks that would be ignored. Workarounds are paid for from funds from the contingency reserve or the management reserve, depending on whether the risk was identified and accepted or whether it was unknown until it occurred. In any case, the funding for the workaround comes out of these accounts and is put into the operating budget of the project, and a new baseline is created.

Since contingency plans and workarounds are not part of the project baselines until they occur, they should be initiated and approved by the execution of an official change notification. Remember that changes to the baselines should require an official change notification as the vehicle for showing the change in funding, schedules, and scope resulting in a new and current baseline.

Project Planning: Evaluating the Political Environment

We’ve talked a lot about the act of planning your project. Review the statement of work (SOW)…check. Review the estimate from Sales…check. Request your project resources…check. Review the draft project plan and revise it – vigorously…check. Plan for your kickoff session with the customer…check.

What hasn’t really been discussed is the act of evaluating the political environment within your organization and the customer’s organization. It may be something you can’t always do too much of up front, but it is something that will have to be revisited and performed throughout the engagement. Here are the basics of what needs to be done up front and revisited in order to more successfully plan your project.

Consider the potential effects for your stakeholders. Once you’ve identified all of your project’s stakeholders, you should take that process one step further and identify who stands to gain (or lose) if your project succeeds and who will gain (or lose) if your project is deemed unsuccessful. It can be of value to understand and appreciate the nature of everyone’s stake in your project. Use this information to your advantage – it can be critical information to have on hand if you need roadblocks removed or key resources and skill sets made available to your project. Stakeholders can help make things happen.

Identify whose support will be needed. Try to identify who’s in the best position to help and support your project. More of the same from above. Keep this list close by throughout the project – because you will hit roadblocks and some of them may not be able to be overcome by your will and effort alone.

Identify who is likely to work against you. Identify the parties who may feel threatened by your project or who, for whatever reason, would not like your project to succeed. What you do with this list depends on the situation. At times, these individuals need to be avoided…and at other times they may need to be included and massaged to help ensure positive results. Power can definitely shift during projects – be aware.

Secure a project sponsor. Identify someone in management who can serve as a sponsor for your project. Sponsors are typically members of management who have a significant amount at stake in the success or failure of your project. Sponsors can work through political issues that are beyond your sphere of influence.

Address unrealistic targets or constraints. If your proposed project targets, specifically schedule and cost, exceed management expectations, you may be forced into a situation where you’re pressured into accepting cost, schedule, or other targets that are unrealistic. If this happens, I’d urge you to pursue either or both of these options:

1. Respond with a data-driven analysis that suggests that the project targets are unrealistic.
2. Continue to publish documents that display your original cost and schedule targets. Once you publish documents with unrealistic targets, you’ve pretty much sealed your fate and doomed yourself to project failure.  Don’t give in…stand firm if you know the targets are unrealistic.

Summary

Careful planning doesn’t guarantee project success, but it certainly doesn’t hurt. Failing to plan is planning to fail. Look at all the angles – consider who can help and who can hurt and act accordingly. You don’t have to make everyone happy – that’s for sure. But there are many eyes on your project and many individuals who stand to benefit from your project success. Know them and use that info to your advantage.

Common Challenges Faced by the Project Manager

Gary Heerkens wrote A Briefcase Book entitled simply “Project Management.”  In it he uses a fictional character, Brad (good choice!) as his subject who has been thrust into the world of project management.  Below is Mr. Heerkens section on the common challenges that he sees project managers being faced with as they lead engagements and work with both their customers and their management structure.  Read on….

Common Challenges You Can Expect to Face

As the Project Manager, can expect to face a number of challenges as you take on the responsibility of managing projects in your organization. Whatever the specifics of your particular situation, however, many of the challenges you’ll face are faced by most project managers. Let’s review a few of these common challenges.

The Responsibility vs. Authority Trap

Firmly embedded in project management folklore is this one: the responsibility you’ve been given is not commensurate with the authority (or formal power) you believe you need to accomplish the mission. The size of the gap between responsibility and authority will partially depend upon the structure of your organization. If you’re in a purely functional organization – and in many cases, a matrix organization – you should not expect to be granted very much formal authority. The gap between responsibility and authority will be quite wide. To compensate for your perceived lack of formal authority, you’ll have to rely upon expert power (respect you can garner through superior knowledge or capability) or referent power (often accessed by practicing an excellent leadership style). You’ll also need to rely heavily upon your ability to influence and persuade.

Imposition of Unrealistic Targets

Sound project management practice suggests that project goals (cost, schedule, quality, and functionality) should be determined through a systematic process of understanding customer needs, identifying the best solution, and formal planning. Throughout this process, realistic assumptions about resource availability, quality of materials, and work process (just to name a few factors) should be used. This approach yields a credible estimation of what is reasonably achievable. If this estimation does not meet business goals, then a systematic risk-vs.-return process should be pursued until it can be verified whether or not the targets can be met within a given level of elevated risk. That’s the process that should be followed.

Unfortunately, we live in a real world. Targets are far too often based on desire or a vague sense of what should be achievable, rather than driven by calculated business needs. In even more unfortunate circumstances, targets are developed before it’s even known what the project entails! In either case, the result is that impatience – rather than a rational process – drives the selection of the targets. From that point on, a desperate struggle begins, as the team tries to force the project to fit within the boundaries that have been drawn.

This practice puts project managers in a very difficult position, as it often sets them up for certain failure and severely undermines the planning process. Unfortunately, this phenomenon seems to have reached epidemic proportion: it’s one of the biggest complaints of practicing project managers today.

Perpetual Emphasis on Function

If you’re managing a project in a functionally oriented organization, one of the more difficult challenges that you’ll face is getting team members to overcome their inherent tendency to think and act in terms of optimizing their own discipline, technical field, or department. It’s important to recognize that this phenomenon is fueled by three powerful influences. First, by definition, projects are temporary, but functions live on. In other words, a person often considers his or her work group to be home; the project is just a passing state of existence. Second, unless contemplating a formal career change to project management, a person considers his or her discipline or area of expertise as the work focus. This means that her or she will likely be committed to ensuring the well-being of that area. This strong loyalty could, for example, give rise to counterproductive situations, such as team members using your project funds to advance their discipline – perhaps in excess of what customer requirements dictate. Finally, there’s the power of the paycheck. Simply stated, most people tend to pledge allegiance to the source of their paycheck. For most people in most organizations, that’s their work group or functional department, not you.

The Dual Responsibility Trap

Most project managers I encounter are asked to wear two hats. They must perform their job duties while acting as the project manager. This situation may present additional challenges for you.

At the center of this dilemma is the issue of allegiance. Imagine for a moment that you’re facing a critical decision. Unfortunately, what’s best for the project will negatively impact your work group but what benefits your work group will hurt your project. What’s the right decision? What do you do? If you make the decision that benefits your work group, you risk being viewed as a poor project manager. If you choose the course of action that benefits the project, you may incur the wrath of your peers and/or departmental management. It’s a tough spot – and you can almost bank on being in it, possibly often.

A more fundamental problem of the dual responsibility trap is figuring out how to divide your time and attention between the two roles. How much should you allocate to each? How long can you try to satisfy both before you realize you’re working most nights and weekends?

Finally, a third issue often surfaces in the form of thetwo boss syndrome. The project manager reports to his or her functional supervisor and to the person who manages the project management function in the organization. Again, this is a difficult situation for most project managers.

The Fundamental Conflict of Certainty and Uncertainty

Many misunderstandings and disconnects between project managers and organizational management can be traced to the fundamental conflict between the certainty that management requires to properly run the business and the inherent uncertainty of project work. Cost and schedule estimating provides us with an excellent example.

Suppose you’re just beginning a project. It’s likely that you have limited information on this project and there’s a significant degree of uncertainty. In a situation such as this, project management practice suggests that you would be well advised to use ranges of values when providing estimates on cost and schedule. The size of your range would reflect a level of accuracy consistent with the extent of your knowledge and the amount of uncertainty. In our example, it would be perfectly appropriate for you to estimate that the cost of your project will be somewhere in the range of $400,000 to $550,000.

Unfortunately, many project managers today would receive a very unfavorable response from their organizational management to that type of “crude” estimate. It doesn’t provide the certainty that management requires for approval.

Unfortunately, this example is not exceptional. The uncertainty associated with projects exists throughout the life of the project: it simply never goes away—nor does management’s craving for certainty.

Balancing Critical Project Success Factors – Engaging Conflicts Directly

This article contains another excerpt from Paul Tinnirello’s book “New Directions in Project Management.” This is the fifth installment in a six-part series entitled Balancing Critical Project Success Factors. In case you’ve missed the first four, here’s what we’ve covered so far:

• Introduction
• Selling Good Ideas
• Building a Common Vision
• Generating a Commitment to Ideas

In this fifth segment we cover engaging conflicts directly and resolving them efficiently and effectively.

Engage Conflicts Directly and Resolve Conflicts Efficiently and Effectively

Once project plans are underway, change happens. Requirements shift, the client does not meet its obligations in the project plan, and budgets can be reduced. Changes within the IT group can also occur. Tasks may exceed initial estimates. Key programmers leave to join other firms. Differences in opinion among IT professionals about the best approach can erupt into conflicts that push projects off track.

When this happens, IT professionals must assertively engage key stakeholders (e.g., users, user management, IT management) in problem solving about the trade-offs that must be made in quality, time, cost, and perhaps even customer service agreements. Assertiveness is critical because users (and admittedly IT management on occasion) would prefer to avoid making necessary but difficult decisions about trade-offs between quality, time, and cost. Interestingly, resolving such conflicts may be best viewed as a typical and not unusual part of what IT project managers do. In survey research of professional project managers, it was discovered that they report spending an average of 12 hours per week resolving conflicts.

When engaged in problem solving about trade-offs, stakeholders sometimes become frustrated and retaliate by challenging the competence or creativity of the IT project manager. IT professionals sometimes respond to such challenges by retreating from their legitimate interests. In a misguided effort to please, some over-commit to all three factors although significant changes in the project environment necessitate adjustments. The result is priority overload, stressed-out IT personnel, a loss of credibility and influence, suboptimal IT work products, or missed timelines.

Assertively championing one’s basic interests, exploring alternatives with affected parties even when they are not enthusiastic to do so, and collaborating to construct win-win agreements is the better response. Unfortunately, many people drawn to information technology (like many drawn to other technical disciplines) have a personal aversion to conflict. Consequently, for some IT professionals, enhanced negotiation skills is necessary.

Faithfully applying project management disciplines can limit the amount and scope of project conflicts that IT professionals have to manage. Conducting risk assessments early in the project life cycle to identify factors that might threaten project deliverables is one such discipline. If a risk is detected early (e.g., weak user management consensus on requirements) and focused problem solving occurs about what contingencies are necessary to address it (e.g., identifying a resource that can be used to do team conflict resolution with user managers), project disruptions caused by the risk can be effectively contained.

Providing regular user management updates is a second project management discipline. When updates work most effectively, not only is progress reported, but threats to project deliverables are reviewed and user management support of efforts to limit or resolve those threats is secured.

For some complex projects, more substantial organizational conflict management mechanisms are required. On large IT initiatives, the relative priority of the needs of different user groups can change over time. Because IT resources are often relatively fixed, reallocating resources to respond to a increased urgency for one user often means reneging on commitments made to other users. To address shifting priorities between users, some IT groups convene regular, periodic meetings of steering committees or users councils. When such mechanisms work well, users collectively learn about urgent priority changes, explore alternative responses to these situations, and finally make mutual decisions about priority changes and IT resource reallocation. In these settings, IT professionals facilitate the preparation of information that enables these groups to make sound decisions. By promoting quality dialogue between users, IT professionals enhance organizational problem solving.

Paul C. Tinnirello is the editor of “New Directions in Project Management” from the Best Practices Series.