Kicking Off a Small Internal Project

Fundamental project management is basically the same across all projects, but how much formal project management practice goes into it does depend a lot on things such as overall timeframe, budget, internal vs. external project, and project criticality and visibility. Let’s face it, these all play a role in how much effort is allowed to go into a project…budget being a huge player.

For small, internal projects that aren’t very visible, aren’t very critical and don’t involve an external revenue generating customer, the circumstances for managing the project and the effort that goes into it are going to be fairly small. For the purposes of this article, I’d like to use Michael Thomsett’s description of how a project manager might kickoff an internal project as described in the Project Announcement Meeting section of his book “The Little Black Book of Project Management.”

I do not necessarily agree with or endorse the information set forth in this article, but I do find the information helpful and it is undoubtedly useful information given the right situation. In a future article I will submit my own viewpoint on the processes for getting a small internal project underway.

The Project Announcement Meeting

Getting your project off to a healthy, well-defined start depends on your approach: how you lead, how you seek definition, and the initial organization of the team, schedule, and budget. But it’s also necessary to communicate your purpose and approach to your team. Thus, a project announcement meeting is essential.

Do you really need an announcement meeting? It may be possible to set the tone and define your purpose without gathering people together; but a preliminary meeting can save a lot of time and effort later, and can help avoid misunderstandings about authority levels and the nature of the assignment.

Example: An accounting manager was assigned the project of setting priorities for automation. The task included interviewing the heads of each department and recommending routines that should be given priority. But the department managers were not advised of the project. The accountant found these managers to be defensive and suspicious; they weren’t sure whose idea the project was, the accountant’s or top management’s. A great deal of effort went into explanation, and the project proved difficult to complete.

This project could have been executed more efficiently if an initial meeting had been called. The accountant and each department manager should have been invited, as well as the executive who made the assignment.

If an announcement meeting is not called at the time a project is assigned to you, recommend calling one. The executive should briefly explain the purpose and objective of the task and clearly identify you as the project manager. Once everyone understands what you’ll be doing, it will be easier for you to organize your project team and contact the resources you’ll need. Most of all, a brief meeting will help avoid your having to explain what you’re doing and why, or having to deal tactfully with other managers who have not been informed about your project.

Support your recommendation for the announcement meeting with these points:

• Announcing a new project defines it for everyone involved, and clarifies the intended purpose. If the meeting is not held, definition will be a problem each time you have to contact a resource.
• The meeting helps ensure success, because everyone gets the message at the same time and from the same authoritative source. Your ability to lead the project team is aided when the project is launched from the top.
• A demonstration of executive support for the project manager helps the team to achieve its goals. However, it’s important to let others in on the decision when they or employees reporting to them will also be affected, either as a team member or as a resource for the team.

If you have identified your project team by the time the announcement meeting takes place, each member should be invited along with individual managers or supervisors of their departments. Introducing the project to everyone—team members and their supervisors—makes your job of working with other departments much easier.

There’s a significant difference between trying to achieve a project task that conflicts with departmental goals and working with other managers to resolve problems. Inviting the managers to the initial project meeting makes them feel included in the process. That sets a positive tone and helps you to function as project manager. The alternative is having to continually struggle with a manager who was left out of the decision-making process at the beginning.

Another Take on the Statement of Work Document

In an attempt to continue to provide PM Tips readers with various templates and descriptions of key documents that are normally part of the project management process, I’d like to present this article with additional information on the always-critical Statement of Work (SOW) document. I’ve already provided much of my viewpoints on this extremely important piece of project information and it’s role in project inception and kickoff in the article “The Statement of Work.”

Here will present more information on this document as described by Carl Pritchard in his book “The Project Management Communications Toolkit.” Mr. Pritchard provides a discussion of the purpose and uses – from his point of view – of the SOW as well as a sample layout of the document.

Since many of the PM readers are looking for help in putting together good templates and understanding how some of these types of documents are laid out and used (especially for the newer PMs or individuals considering a PM career) I feel it is critical to provide our readers with as many examples of these tools as possible.

The Statement of Work

Purpose

The statement of work serves as a guideline of the agreements on performance between a purchasing organization and a seller of goods and/or services. It is frequently an attachment to a contract or a memorandum of understanding between two organizations. The SOW affirms how the purchasing organization wants the work to be performed and the context of that performance, including any specific management practices or protocols the contractor must follow.

Application

The SOW is normally used as an attachment to the contract or agreement and is one of the very earliest documents developed to clarify communications between organizations. As a component of the contract, it is frequently used to settle disputes over what work should or should not be included in a project. It establishes expectations for a variety of issues in the contract relationship, including (but not limited to) the following:

• Overall project scope
• Primary tasks and/or deliverables;
• Costs
• Reviews and reports
• Testing
• Support
• Performance requirements
• Period of performance
• Payments and invoicing

Because the SOW is normally an attachment to the contract or agreement, it is a primary reference document for the project manager throughout the life of the project.

Content

Because the SOW is most often developed by the organization requesting the project product or service, it normally reflects a functional, rather than technical, perspective. Although the customer may have technical expertise, the work they will identify in the SOW is frequently performance oriented or performance based.

An outline for a SOW might look like the following:

1.0 Project Scope and Objectives

This is often a rewrite (or a copy) of the scope statement for the project, providing a general, overall perspective on what the project is intended to accomplish.

2.0 Description of Deliverables/Services

If the project can be defined into the key components or elements of the deliverable or service, they should be defined in sufficient detail to guide the project organization on the buyer’s desired approach. This may include physical deliverables or reports, testing, and support components of the project. The description of deliverables and services is normally the single longest section of the statement of work.

3.0 Costs

In an internal or cost-reimbursement contract situation, a table for the anticipated costs by deliverable, month, quarter, or fiscal year may be provided. This would not be included in a firm fixed-price contract. This may include personnel and materials usage and rates, particularly in a time-and-materials contract.

4.0 Reviews and Reports

This is a detailed description of the regular reporting requirements associated with the project and the level of depth anticipated for those reports. It may include not only timing for the reports, but also the forms and formats required.

5.0 Testing

The testing component details what types of tests are considered mandatory and how and when they must be applied. This may include both formative (in-process) and summative (upon completion) evaluations.

6.0 Support

This component may describe support both during and immediately following the project. It should include some details about response times, type(s) of support (telephone, on site, e-mail, chat, and so forth), and what general areas may or may not be covered as a component of the support agreement.

7.0 Performance Requirements

If any specific organizational protocols must be followed, they should be included in the SOW. This might include security, team behavior, configuration management, risk management, and other managerial requirements of the purchasing organization.

8.0 Period of Performance

This should be a date-certain window of performance for the contract, from [date] to [date], with no work to be performed outside that window without a contract amendment.

9.0 Payment and Invoicing

This should provide specific guidance on any provisions for interim payment and identify any specific individuals responsible for ensuring payment in a timely fashion. It may also cross-reference any protocols for invoice submission.

Approaches

In some contracting organizations, the SOW is used as a place to incorporate any special contractual clauses that may not normally be embedded in the contract. If the organization does not normally have a “furnished property” clause or other clause that may directly affect performance, such clauses are sometimes included here. In other organizations, clauses that are nestled deep within the contract, but which are often overlooked, are repeated here for emphasis. The purpose of the SOW is to clarify what work is to be performed by the project organization. If those clauses have direct influence over how the work will be performed, their inclusion here may be appropriate.

Some organizations use SOWs even for internal projects. In such environments, the SOW is used to emphasize the contractual nature of the relationship among the functional managers who may be responsible for the effort.

Considerations

Project managers frequently use the SOW as virtually the sole arbiter of how they will move forward on the project. In some organizations, the SOW is the only customer-authored documentation the project manager ever sees. The project managers may not have access to the full contract, but they almost always have access to the statement of work. As the guiding force for project performance, regardless of legal consequence, the SOW is likely to be seen by the project organization as the final determinant of what the customer wants.

The Formal Project Request

Depending on the size of your organization, and of course whether you’re dealing with internal or external projects, it may or may not be beneficial to have a formalized project request process.

I ran only internal projects for a very large aviation and engineering firm in the late 1990’s and early 2000’s and our web development team had created a formal online project request process that captured key information for each project request. What that gave us was a standardized type and amount of key information for each project that came through making it easier to prioritize and assign the projects to the correct areas of our department (based on the business units they supported and the type of project that was being requested).

In Carl Pritchard’s book “The Project Management Communications Toolkit” he outlines what should be contained in a general project request document and what it is used for. Again, this all depends on which organization is originating the project request. If you’re dealing with external customers, your internal formal project request still may serve you well as a means to get consistent types of project information loaded into a common database from which you manage your entire portfolio of projects. No matter how it is performed or where the project request originates, a common process is usually helpful and recommended.

Much of the following text comes from Mr. Pritchard’s section providing his take on this process – however, I have taken liberties to add some of my own thoughts and details to his text.  I believe that his process, for the most part, does a pretty good job of laying out the information that is important to capturing the project request.

The Project Request

Purpose

Because different organizations interpret project requests (as a practice) differently, their purposes may vary as well. A project request may be a simple one-paragraph description of a project that has been formally submitted to management (either through a chartering process or proposal process). It may also be a specific form or format for submitting initial information about a project that may be of interest to the organization or that may serve an organizational need. For the sake of this discussion, the latter is assumed.

Application

A project request is used as a means to initiate ongoing analysis (feasibility study, impact analysis) of a project concept. Information available for the project request is generally somewhat scant, as the project request is used only to trigger other processes.

Content

A project request form includes only the most rudimentary information about a project concept:

• Project name (or a few-word description)
• Project description (may include a brief description of the goals or objectives of the project, as well as any problems/concerns it is designed to resolve)
• Timing
• Special resource needs (may include material or human resources essential to project initiation or implementation)
• Support organization (the anticipated “home” for the project if it is determined to be viable);
• Name of person completing the form
• Budget and Sponsor information
• High-level business case
• Criticality of need (aids in project prioritization especially for internal projects)

Although other information may be incorporated, these are the essentials for initiating a project and ensure that a consistent baseline set of information is available for any project that will undergo further study or scrutiny.

Approaches

The information embedded here may be redundant with information collected for a project proposal or feasibility analysis. That is why, particularly in smaller organizations, a project request form may be embedded within those other processes. Larger organizations use project request forms as an initial screening mechanism to enter projects into the process and to ensure that those that undergo more formal feasibility assessment are initiated at the appropriate levels within the organization.

Considerations

Because the project request form data are frequently redundant with information gathered in other processes, it should be applied only when there are copious requests being filed on a regular basis, the organization is large, and tracking mechanisms are limited. In smaller organizations where project owners are easily identified, project requests may be seen as purely administrative overhead.

The Project Business Case

Every project needs a business case. This may be informal – especially for small and/or internal projects. It may also be very formal, as is likely the case for very large and very visible projects run for customers outside of your organization. In most cases, the customer has put together a business case in order to gain their own funding for the project. In some cases, they’ll need your help – as the project manager – in putting together the project business case and thus justifying the project and associated expenses to others within their organization.

Below is Carl Pritchard’s take on the Business Case documentation as outlined in his book “The Project Management Communications Toolkit.” I found it to be an interesting read and hope that some PMs find this of value on the projects they are working or getting ramped to work on.

The Business Case Documentation

Purpose

The business case establishes the fundamental rationale for a course of action. It is the documented history of why a project, effort, or approach was selected. It details the objectives, the projected outcomes, and the projected investments associated with the effort. As such, it allows decision makers to examine the breadth of information currently known about the effort to determine whether or not the project is a good idea in terms of cost, benefit, and organizational objectives. It may include statements about the impacts on existing business practices, resource constraints, and environmental considerations so as to provide a comprehensive understanding of the project. In some instances, risk analysis is a key component. It is the primary document defending the rationale for the project.

Application

The business case is normally applied early in the project and may be developed by senior management, marketing groups, the project office, or by any group or organization responsible for initiating large-scale activity within the organization. Business cases in mature organizations follow consistent formats to allow managers to review multiple projects in similar contexts.

The business case will list the key proponents of the project, the sponsor, the users or beneficiaries of the project, and any deliverables. At a high level, it will describe the approach to be used and the business justification or rationale for that approach. Normally, that rationale will incorporate some form of cost/benefit analysis, although the types of cost/benefit analyses and their applications vary widely.

A general outline for a business case might look like this:

• Executive Overview
• Project Description
  • Proponent(s)
  • Sponsor(s)
  • Users/Beneficiaries
  • Deliverables and Quality Criteria
  • Rationale
  • Cost/Benefit
  • Schedule/Time Frames
  • Communications and Reporting Requirements
• Environmental Considerations
  • Project Development Environment
  • Project Implementation Environment
  • Organizational Processes
• Risk Factors/Risks
  • Risk Management Approach
  • Preliminary Risks Identified
• Assumptions

Content

The information supporting each of those outline components should be developed as objectively as possible. To achieve that, each element should be reviewed by at least one other person. The content may be expanded (or compressed) based on the business needs of the organization conducting the analysis. At a high level each section should contain the specific information discussed in the following subsections.

1.0   Executive Overview

The executive overview is a general scope statement identifying the time, cost, and requirements for the project, as well as the business need driving the effort. It should include the names of the project sponsors and project manager, as well as a description of the beneficiaries of the effort. The executive overview should provide a synopsis of the cost/benefit analysis, regardless of whether those costs and/or benefits are tangible or not.

2.0   Project Description

The project description should provide more depth on most of the issues raised in the executive overview, including the background, sources, and history for any data provided as rationale for the project or the cost/benefit analysis. This section may include cross-references to other project documentation, including draft plans, product descriptions, and stakeholder analyses or surveys.

3.0   Environmental Considerations

The cultural, technical, or physical environment may described here in depth, providing information on the practices and protocols typical within the environment.

4.0   Risk Factors/Risks

The risk approach described here may include the means and practices to

be employed for risk identification, qualification, quantification, response development, contingency allocation, and risk reassessment. Any initial or signifi

cant risks identified in developing the preliminary information (like the cost/benefit analysis) should be identified here as well.

5.0    Assumptions

Assumptions are beliefs that are held as true to allow for ongoing planning. In an effort to ensure that they have value, assumptions identified here regarding all aspects of the project (resources, environment, client culture, organizational behavior, and so on) should be validated as practicable.

Approaches

Business cases in some organizations may be voluminous and detailed. Others span only a page or two. Regardless of the level of depth, they should provide insight into the considerations that were used to determine if there is a valid business reason for moving forward with a project. They should be directed at an internal audience, because they may include information about the internal response to and structure for the customer relationship. The internal audience should, at a minimum, include the project sponsors, the project manager and executive management.

Considerations

Because the business case may contain sensitive competitive information, it should be disseminated only to those who have achieved a level of trust within the organization. The author of the document should be clearly identified, and contact information for that individual should be included as well. Although the business case is an initiating document, it should be reviewed and revisited on a regular basis to ensure that the cost/benefit analysis and proposal are still being pursued.

Estimating the Project

Most of what I’ve written so far assumes that the project manager is usually in a situation where Sales has closed a deal for a project and the information is passed on to the Professional Services portion of the organization for execution. The project manager is assumed – unfortunately – to have little to no input into the estimation/sales portion of the project and he or she basically gets what they get. That would be in terms of negotiated resource hours, dollars/budget, and the statement of work (SOW).

Jason Charvat writes, in his book “Project Management Nation,” about the estimation process form the PM perspective – this would coincide with the type of work I performed earlier in my career where all high-level requirements gathering, estimating, pricing and negotiating the engagement with the internal business sponsor (these were all internal projects at a major corporation) rested on my shoulder. Talk about control…I loved it. Here is Mr. Charvat’s section from his book – this covers what he calls the estimation process.

The Estimation Process

The project manager should remember that the estimation that results from the planning phase is not final and is considered a temporary estimate. Once more detailed project planning is performed and the project costs and WBS schedules are fine-tuned, a more accurate estimate emerges. Basically, the estimation process has a few primary steps:

• Develop the WBS.
• Estimate each part of the WBS constituting the total project.
• Schedule the work according to each WBS task.
• Determine the resources needed, quantities, and availability.
• Obtain the latest resource rates, including next salary reviews and increases.
• Determine the level of effort needed to complete each WBS task.

Something that is very important during the estimation process is that project managers ask the client to pay a price that is relevant to the perceived value of what they receive. If the client is willing to pay for the project, the project manager needs to determine whether it is profitable enough to do the work. To determine this, project managers must determine cost. This is where the estimation is needed.

What to Include in a Project Estimate

• Internal labor or cost of employees – Burdened cost to company—benefits included
• Hardware costs – Servers, printers, workstations
• Software and licensing – Application software, downloaded software patches, code
• Travel and accommodation – Airfares, hotel, tolls, gas
• Administrative support costs – Personnel, finance, and legal support
• Training costs – User training, computer-based training, lesson plans
• System documentation costs – Manuals, policy & procedures, on-line documentation
• Stationary costs – Project stationary
• Infrastructure costs – Office space, desks, rent, parking

Estimating the Effort

It is said that you cannot manage what you cannot measure. No matter what project a project manager has been allocated or assigned too, the project estimate should include the following:

• Size of the project
• Resources required
• Project duration
• Costs needed to complete the project, labor, hardware, travel, etc.

Estimates in the IT industries are incredibly difficult to complete due to so many unknowns. The initial estimate is, in many ways, the most important. The initial estimate will be a focal point with which the project manager can compare all future estimates. Because of this, there are several recommended steps to follow when achieving an initial estimate.

• Break down the project requirements as far as possible to subsystem levels (WBS).
• For each WBS element, identify its similarities with previously developed projects and use this historical data.
• For those WBS element units not strongly related to previous IT projects, use SMEs to estimate the size of those elements needed.
• Form the size estimate for the entire project by rolling up the estimates for all the WBS elements.
• From historical data and expertise, estimate the level of effort.
• Divide the size estimate by the work rate to obtain an estimate of the effort in work hours.

Once the WBS has been developed, many project managers move directly to determining the duration of the task. This is normally done using a software tool, and it visually appears as though the project manager is on the right track. This is not the correct approach; it creates room for errors and bad planning. Remember that it takes a lot of skill and experience to estimate all WBS tasks. For example, it can take one seasoned IT architect a few hours to do a server capacity assessment, but the same task could take two junior IT architects double the amount of time to perform.

Similarly, a situation may arise where only one person can do a specific task, such as cloning a server. Only one resource can do the specific task, not two. Therefore, in this case, the emphasis is on ensuring that the resource is best-qualified to perform this task. The project manager also needs to discuss the issue with an SME to determine the amount of effort. The cost per task is directly related to the resources and effort needed. The project manager must accommodate the level of effort needed to perform the task.