Project Management Templates

Over the past several couple of weeks I’ve discussed many project management-related templates and documents that are commonly used. And along the way over the past 10 months there have been a few other templates and documents discussed.

In an attempt to provide a one-stop document to link to all those templates and documents discussed so far, I’m going to pull them all into this article as a list with available links. Hopefully, having the accumulated list available in one place will be helpful to our readers.

Again, not all of these will be links to templates…some will merely be links to documents that have been discussed in greater detail in previous articles.

• Statement of Work
• Project Status Report
• Communication Plan
• Communication Plan
• Risk Management Plan
• Lessons Learned
• Lessons Learned
• Requirements Traceability Matrix
• Market Analysis
• Project Management Methodology
• Quality Management Plan
• Project Request Document
• Project Charter Document
• Business Case Document
• Change Order Request
• Change Order Request
• Resource Request
• Onsite Visit Progress Report
• Procurement Plan
• Lessons Learned Survey
• Disaster Recover Plan

Summary

As discussed in most of these articles, if having the actual template in a Word doc format would be helpful, just let me know and I’ll be happy to send it to you if I have it. In some cases, I may be able to send you an actual example document from a real project allowing you to better see how I’ve populated some of the information with meaningful data. I’ll revise and republish this article as I make more templates and documents on these and similar topics available that I think would be useful to our readers.

The IT Auditor’s Role in the Software Development Process

In further examining the IT Auditor’s role in the IT project environment, I’d like to look at how the book “Information Technology Control and Audit” discusses the IT Auditor’s role in the overall software development process.

Software Development Process

A formal systems development process provides an environment that is conducive to successful systems development. This includes: (1) an information systems strategy that guides developers in building systems that are consistent with the organization’s technical and operational goals, (2) standards that guide in the selection of hardware, software, and developing new systems, (3) policies and procedures that support the organization’s goals and objectives, and (4) project management that ensures projects are completed on time and within budget. Auditors can assist organizations by reviewing the systems development process to ensure that developed systems comply with the organization’s strategy and standards.

Software Development Phases

The systems development process can be broken down into four phases:

• Planning
• Development
• Implementation
• Maintenance

The planning phase sets the stage for the success of the development effort. If not done properly, the budget and schedule may not be sufficient, the problem may not be adequately defined, the final project may not solve the business problem, and the right people may not be involved. The planning phase of systems development includes the following activities:

• Needs analysis: a study to determine whether a new system should be developed
• Current system review: a study of the current system to identify existing processes and procedures that will continue in the new system
• Conceptual design: preparation of the proposed system flow and other information illustrating how the new system will operate
• Equipment requirements: hardware configuration needed to process and use the new systems (e.g., processing speed, storage space, and transmission media)
• Cost/bene?t analysis: detailed financial analysis of the cost to develop and operate the new system, the savings or additional expense, and the return on investment
• Project team formation: identify people from programming, user departments, and support departments to develop and implement the new system
• Project plan: an overall project plan with defined tasks and deliverables to monitor actual results and ensure successful progress

Auditing can be involved in the planning process to develop an understanding of the proposed system, make sure time is built into the schedule to adequately define controls, and verify that all the right people are involved.

There is a definite correlation between a well-managed systems development process and a successful system. The use of a proven system development methodology increases the probability that the system’s internal controls will be effective and reliable. As discussed under the traditional development approach, systems development includes the following phases:

• Analysis: Define what is required of the new system.
• Design: Define how to build the new system to satisfy the requirements.
• Construction: Build the new system using the design information.
• Testing: Verify that the completed system meets the users’ needs and functions without fault.
• Implementation: Deliver the completed system to the end users; obtain satisfactory feedback.
• Maintenance: Modify the system as needed to correct problems or meet changing needs.

Auditing can review the development process to ensure the software is designed with user requirements documented, that management approves the design, and that the application is tested before implementation. An additional focus is ensuring that the end user is able to use the system based on a combination of skills and supporting documentation.

Phases of a Construction Project Life Cycle – Part 1

Having almost exclusively only dealt with and led IT software projects throughout my career, I’ve always been intrigued by the area of construction project management. Though with my background, getting in the door – even on a consulting basis – to gain that experience just hasn’t happened or the timing was just never right – either in the Midwest or in Las Vegas during the housing boom.

So running across F. Lawrence Bennett’s book entitled “The Management of Construction – A Project Lifecycle Approach” peaked my interest. I’ve written about project lifecycle and methodology phases at great lengths in my articles and would like to present here Mr. Bennett’s parallel segments on the construction project lifecycle. Due to the length of the material, this will likely need to be shared over multiple parts starting with his general overview for the purpose of this article. The following text was derived from Mr. Bennett’s Management of Construction book.

Overview

Every project, not just those in the construction industry, goes through a series of identifiable phases, wherein it is ‘born’, it matures, it carries through to old age and it ‘expires’. A software development project manager, for example, might define the following phases in the project’s life cycle: initial proposal, process engineering – requirements analysis, process engineering – specifications, design, development, testing, deployment and support. Likewise, a project that results in the development of a new product might contain the following phases: conceptual, technical feasibility, development, commercial validation and production preparation, full-scale production and product support. Although there may be some overlap in the phases, the work generally flows from the first phase to the last, with the outcome of one phase providing the basis for efforts carried out in the phase that follows.

So it is also with construction projects. We will be identifying six phases in the construction project life cycle, each with its own purposes and characteristics. First, the owner must make certain pre-project decisions. Then the planning and design of the project is carried out. Next, the contractor is selected, after which the contractor mobilizes in order to carry out the field operations. The field work that the lay person often considers to be ‘construction’ can be considered a separate phase. Lastly, the project must be terminated and brought to a close; because these activities are distinct from the installation work, we separate them into a distinct, final phase.

To attempt to understand the management of construction by organizing the study on the basis of the project life cycle may be somewhat arbitrary, because there is admittedly some overlap between phases and thus some duplication in the presentation. However, this deliberate design of this text will provide a logical basis for tracking the project’s activities and understanding the roles of the people responsible for those activities, from the time the owner first conceives the idea for a construction project until that point when the contractor has vacated the site for the final time.

Structured in this way, each section provides a description of one of the project’s phases. The result should be an understanding not only of the importance of each phase individually but also of the way they interrelate to form an integrated whole project.

In Part 2, we will present an overview of each of the six phases of the construction project life cycle.

A Project Management Historical Timeline

While reviewing my latest copy of Project Manager Today – a UK-based PM magazine – I was reading their article entitled “A Profession is Born” which looks back on the 20-year history of the publication. Included in the article is a timeline of some key points in project management history – though with a very UK twist to it.

I decided to put together a more all-inclusive timeline by grabbing some info from Wikipedia and whatever other sources I could find.  The resulting timeline follows – I hope you find it as interesting as I did. If you have anything that should be added or revised – please let me know…I’m always interested in accuracy and completeness.

Project Management Timeline

1910s

• 1910 – The Gantt Chart developed by Henry Laurence Gantt (1861–1919)

1950s

• 1954 – Bernard Shriever (US Air Force) coins the term Project Management
• 1956 - The Critical path method (CPM) invented by Du Pont employees
• 1956 – The American Association of Cost Engineers (now AACE International) formed
• 1958 – The Program Evaluation and Review Technique (PERT) method invented and used on the Polaris project

1960s

• 1962 – DoD/NASA publish a description of the Work Breakdown Structure (WBS)
• 1967 – The International Project Management Association (IPMA) founded in Europe
• 1969 – Project Management Institute (PMI) launched to promote project management profession

1970s

• 1973 – International Computers Limited (ICL) offer PERT on a mainframe computer
• 1974 -PROMPT method launched (later known as PRINCE2)
• 1975 – PROMPTII methodology created by Simpact Systems Ltd (source: PRINCE2 manual)
• 1975 – The Mythical Man-Month: Essays on Software Engineering by Fred Brooks published
• 1979 – Central Computer and Telecommunications Agency (CCTA – later known as Office of Government Commerce or OGC – UK) adopt PROMPT II

1980s

• 1980 – First ‘on screen’ bar chart on early PCs
• 1981 – UK Army adopts PROMPT method
• 1984 – The Goal by Eliyahu M. Goldratt published
• 1986 – Scrum was named as a project management style in the article The New New Product Development Game by Takeuchi and Nonaka
• 1987 – First Project Management Body of Knowledge Guide (PMBoK) published as a white paper by PMI
• 1989 – PRINCE method derived from PROMPTII is published by the UK Government agency CCTA and becomes the UK standard for all government information projects

1990s

• 1996 PRINCE2 published by CCTA (now OGC) as a generic product management methodology for all UK government projects.
• 1996 – First published edition of the PMBoK appears
• 1997 – Critical Chain by Eliyahu M. Goldratt published

2000s

• 2000 PMBoK second edition published
• 2001 Agile Alliance formed to promote “lightweight” software development projects
• 2004 PMBoK third edition published
• 2006 Total Cost Management Framework release by AACE
• 2008 PMBoK fourth edition published

The Unofficial Tasks of a Project Manager

Recently, I’ve presented a few excerpts from Gary Heerkens’ brief case book entitled “Project Management.” The book contains some very interesting concepts and the excerpt presented in this article is no exception. This section of the book discusses the “unofficial” duties of a project manager. Mr. Heergens defines these as babysitter, salesperson, teacher, and friend. Please read on and I’ll discuss further following the excerpt.

The Project Manager’s “Unofficial” Job Duties

Functional competencies (previously discussed in the book, not included in this article) represent official duties of the typical project manager. In fact, if your organization has developed a job description for project managers, it probably includes many of these functional competencies. What you won’t find in job descriptions are the unofficial duties that project managers perform in the course of carrying out their mission. Let’s examine some of the key ones (somewhat tongue in cheek).

Babysitter—This refers to the apparent need to provide close guidance or detailed instructions to certain individuals. This situation results from any number of root causes. The target may be under qualified, lack confidence, or simply crave attention.

Salesperson—There will be times when you’ll have to rely heavily on your ability to influence others to sell an idea, sell yourself, or perhaps sell the virtues of project management. Most of your selling situations will be helpful and have positive outcomes. However, if you find yourself spending too much time selling project management, that may signal deeper underlying problems, such as issues of trust or confidence. If most of the selling you do is to your management, you’re in trouble. This is a signal that your life as a project manager may be exceptionally challenging.

Teacher—This is an example of an unofficial role that actually yields positive results. In fact, superior project managers will be able to educate and develop those they work with as they manage the project. Acquire this skill or reputation and you’ll be in very good shape.

Friend—Maintaining friendships and professional relationships with the same people is difficult. However, if you can do it, you’ll benefit greatly. An open, informal, and comfortable communication linkage is much more likely to keep you supplied with more of the information you need than formal, rigorous, and stiff team meetings. Finally, avoid the trap of believing that because you’ve been put “in charge” of a project you’ve risen above your peers and friendships no longer matter. Big mistake!

Conclusion

I agree with Mr. Heergens’ “unofficial” tasks and could probably add a few myself, but rather I would like to discuss the four he identifies in this section.

Babysitter – As a project manager, you’re responsible for the overall project and its ultimate success, though much of the factors that go into its success or failure are somewhat beyond your control. Babysitting the project staff is hopefully something you won’t have to do too much of. Ideally, you’ll have an experienced and skilled staff. If you have project team members that require too much babysitting and are not productive members of the team – or are displaying rogue behavior and not staying on task – then it is time to bring it to their immediate manager’s attention and either get the behavior rectified or have them replaced on your team.

Salesperson – I agree with this one. The project manager continually must sell. They have to sell themselves and their ‘billable’ status to their customers on some projects. They have to sell change order situations to their customers. They have to sell the criticality of their projects to internal management in order to gain the experienced resources they need for important tasks on their projects.

Teacher – This can go two ways. In the teacher role, the PM is often mentoring a less experienced project manager or one who is new to the organization and, therefore, the organization’s PM methodology and process. They also act in the teacher role to their project staff and make them aware of the responsibilities each team member has on the project, the processes they need to follow and that tasks they are to perform.

Friend – This is a difficult one. Friendships are great, but having close friends work for you on projects as you try to manage and guide the team can be difficult and can even cause problems. Friendly relationships, though, are important. A friendly, cohesive team usually has a higher chance of success than one that is purely professional or has some internal strained relationships or power struggles.