Getting the Project Planning in Motion

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

This article is based on information from “The Portable MBA in Project Management,” by Eric Verzuh.

Assembling the who, what, and when of a project can be a difficult task. Even small projects can have an overwhelming amount of detail. Fortunately, project management and project planning techniques have evolved to provide a systematic approach for breaking the project down and assembling the details in an organized, informative format. Let’s look at what I consider to be the six basic steps to go through in the process of planning your project out in detail:

• Build a work breakdown structure (step one). The project manager and team identify all the tasks required to build the specified deliverables. The scope statement helps to define the boundaries of the project.
• Identify task relationships (step two). The detailed tasks are placed in the proper sequence and interdependencies of tasks are identified.
• Estimate work tasks (step three). Each of these detailed tasks is assigned an estimate for the amount of labor and equipment needed and for the duration of the task.
• Calculate initial schedule (step four). After estimating the duration of each work task and figuring in the sequence of tasks, the project manager team calculates the total duration of the project. This is just an initial schedule at this point – it will be the basis for managing the remainder of the project and will need to be revised continually.
• Assign and level resources (step five). The project manager team adjusts the schedule to account for resource constraints. Tasks are rescheduled to optimize the use of people and equipment used on the project.
• Develop the budget (step six). Combine the costs associated with materials, labor, equipment, and external services to create a detailed cost estimate and cash flow projection. Whether this is done top-down or bottom-up depends on your organization, your project management practice and how much control the project manager has. Sometimes the estimate is already in hand and it dictates the schedule, unfortunately.

These steps generate all the information required to understand how a project will be executed. The steps are systematic, but they don’t necessarily always come up with the “right answer.” Again, depending on how much control the project manager has over the project management process this overall process can take on different looks. However, one thing is a given – it may take cycles of these steps to find the best balance between cost, schedule, and quality.

What Goes into a Good Statement of Work

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

This article is based on information from one of my favorite PM books – Eric Verzuh’s book entitled “The Portable MBA in Project Management.”

The statement of work (SOW) basically kicks off the project management process and is meant to document the goals and constraints of a project. However, it cannot and certainly should not attempt to document every agreement about the project. There are other project and project management documents for this purpose – requirements, specifications, customer acceptance tests, and also you basic output of agreements and notes from kicking off the project with the customer. The SOW should record the goals and constraints for managing the project. While that can contain a wide range of information, the minimum content listed here gives you an idea of what makes up a good, useable SOW:

• Purpose statement: A clear description of why we are doing this project.
• Scope statement: A description of the major activities of the project in such a way that it will be absolutely clear if extra work is added later on.
• Deliverables: A list of outputs the project will produce, including intermediate deliverables, end deliverables, and deliverables related to project management.
• Cost and schedule estimates: In addition to a budget and a deadline, a description of how flexible the budget is and the rationale behind the deadline.
• Project objectives: The specific, measurable goals of the project.
• Chain of command: An organization chart that spells out who makes decisions and to which superior problems will be reported. It is often a good idea to include the organization chart of the customer, as well.

The SOW is a tool for managing expectations and dealing with change. When disagreements arise after the project has started, they can sometimes be solved by simply reviewing the original SOW. However, it is also true that the original agreements and assumptions may change during the course of a project. In this case, all stakeholders must understand and agree to these changes, and the project manager must write them into the SOW or track them through other project management processes such as change orders. The SOW that remains at the end of the project may be very different from the original document. The amount of this difference is not important; what is important is that everyone has been kept up to date and has agreed to the changes.

The Project Quality Assurance Role

Quality Assurance is often seen as an integral function that monitors and coordinates the quality used within the project management life cycle by evaluating the processes and procedures. Quality control, on the other hand, can be seen as a focused area (such as software testing) that compares the product to the specification or plan, with a focus of detecting and remediating errors or anomalies.

Therefore, the Quality Assurance role is a critical factor in the success of the overall project as it is focused on key quality functions throughout an engagement. In his book “Project Management Nation,” Jason Charvat identifies the following key duties for the role of quality assurance throughout the project management life cycle.

The Role of QA on the Project

The person who is responsible for QA has many duties and responsibilities. The following section lists many of the things that a QA person would be expected to do.

• Participate in the change management process to assess the risk of putting fixes into the environment during acceptance testing.
• Assist the test team in isolating the source of discrepancies between expected and actual test results. If the error is in software design, thoroughly analyze the ramifications of any design changes. Design diagrams and structure charts before proceeding with corrections to code.
• Complete preparations for acceptance testing, including the establishment of the acceptance test environment. Unlike system testing, acceptance testing always takes place in the targeted environment. It is therefore extremely important to schedule computer resources well in advance.
• Check the simulated data to ensure that required test data have been produced.
• Obtain expected results from the acceptance test plan and review them for completeness.
• Calculate any missing expected results.
• Be certain that the introduction of new load modules is according to test configuration management procedures. When a new, corrected load module is received, first rerun tests that previously failed because of software errors. If these tests succeed, proceed with regression testing.
• Analyze and report test results. Evaluate test results as soon as possible after execution. Wherever possible, use automated tools in the analysis process. Record analysis procedures and keep all relevant materials. Remember that records and reports should give complete accounts of the procedures followed. If a test cannot be evaluated, note the fact and report the reasons for it.
• Compare all test results with expected results and note that all defects are documented, regardless of how minor they appear or whether they will be corrected.

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.

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.