Maintaining Project Control

This 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.

Information for this article is based on a section of Eric Verzuh’s book entited “The Portable MBA in Project Management.”

The Control Process

The project control process is designed to spot problems early, while they are still small enough to correct. It is an iterative feedback loop in which the project manager uses measurement and testing to evaluate deviations from the plan as to cost, schedule, quality, and risk. These deviations may or may not result in corrective action. The key is to monitor closely enough and often enough to spot such deviations before they get out of control. There are five steps in the project control process: Read more »

A Template for Formal Project Acceptance

This article describes the Formal Acceptance Document. This is just one example – I have other templates to provide at a later date – but I will go into some of the specifics concerning the document and provide some template text for the document itself. This is primarily for acceptance of a deployed system or project, but could also be modified to provide signoff for a specific deliverable document during the project such as a test plan or business requirements document.

Formal Acceptance Document

Purpose

The formal acceptance document captures the concurrence of the customer, sponsor, and other stakeholders that the project has been completed and meets its objectives. The most common form of formal acceptance document is the customer acceptance document, acknowledging that the project has been developed as the customer originally requested.

Application

Formal acceptance is used as the legal acknowledgment that the project deliverables have been delivered as intended. It is used to certify the project as complete and to release the project organization from any future obligations. Because of the important and heavily contractual nature of the document, it is normally developed early in the project and reviewed with the customer. It is then preserved and used during the phase or project closeout processes.

Content

A formal acceptance document may be presented as a form or a letter. It will provide detail on the date of origin of the project, the project name, and the degree (if not total) of acceptance. In that the document requires a customer signature and is normally initiated by the project organization, it must be designed to ultimately cycle back to the project organization after being signed. It may reflect any interim or milestone acceptance documents that have been exchanged, but should serve as the ultimate determinant that the customer accepts the deliverables as generated.

{Customer}

This letter is to certify that all deliverables under project [name/number] have been delivered in accordance with the contract/agreement dated [date]. Interim approvals for these deliverables were accepted and signed on [dates]. This serves as affirmation that the latest and final deliverables under the project agreement have been conveyed, and we seek your concurrence.

If there are any outstanding issues or concerns that have not been addressed please alert [name] of our organization as soon as possible. We have appreciated serving you in this effort and look forward to our ongoing relationship. Please sign two copies of this letter, keeping one for your records and returning the other to us via the enclosed self-addressed, stamped envelope.

[Signature]

X______________________ (Signature of Customer)

Date___________________

Approaches

Note that the customer acceptance letter does not go into a great deal of detail about the nature of the relationship, the type of work that was being performed, the level of effort, or the specifics of the project. In a formal acceptance document, the key is to reference a primary documentation source (like the contract) and to garner the customer signature. Some customers may perceive any supplements to the formal acceptance document as contractual addenda or as their approval or acceptance of certain behaviors or performance aspects that were not specified within the contract or project agreement.

As to the choice of a letter or form for formal acceptance, the letter creates more of a sense of professional warmth, whereas forms may be perceived as cold or pragmatic. Both serve the same function, but the nature of the relationship or corporate protocols may drive the use of one versus the other.

Considerations

Because the formal acceptance document requires a commitment on the part of the customer, and because that commitment releases the project organization from further obligations (except for those outlined in the contract), some customers may use the issuance of the formal acceptance document as an opportunity to extract last-minute concessions from the project organization. It is important to note that the acceptance document reflects the project as contracted, and although organizations may choose to accede to the customer’s late requests, any major shifts in project approach or delivery may need to be acknowledged as either contract addenda or within the body of the formal acceptance document.

Managing Project Change Control

In my never-ending quest to bring you different points of view on specific topics and not just subject you to whatever I decide to write, I’d like to present to you a section from Jason Charvat’s book entitled “Project Management Nation.” This portion deals with the concept of project change control. I’ve previously discussed in several of my articles ways of dealing with scope management and the handling of change orders. I will now present a similar discussion from Mr. Charvat’s book.

Project Change Control

Change can be generated by anyone, but this is not to say that the required change will be actually implemented on a project. Changes to a project may be a result of a (1) deviation or waiver, (2) issue management process, or (3) a change in scope as requested by the client.

If a deviation is identified from the agreed-upon assumptions and constraints, or if the client is unwilling to meet their obligations, a change in the project or the project targets may result. Resolving an issue may mean changing the way the project is being approached or changing scope. In many cases, there may be a clear modification to scope wherein the client requests additional functionality or deliverables, or perhaps even a reduction in functionality or deliverables.

Developers and designers sometimes introduce technical “requirements” to a project that do not actually contribute to the business success of the project. Essentially, no matter how “nice” something is, it should not be done unless there is a clear business benefit that is within the scope of the project.

Project managers should at least be aware of new requirements before they are implemented. Many projects suffer from users, business analysts, and even technical architects wandering from developer to developer and inserting “good ideas” into the project. While this is done with the best of intentions, it has a terrible impact on the schedule and must be controlled. This is not to say that all “techie” tasks should be dismissed out of hand; however, things that are necessary should be sold to the business on the basis of benefit to the business, and they should be included in the business requirements for the project.

Change Control: A Process

It is important to control the change requests that are proposed during the course of the project. The following step-by-step process will help project managers implement successful change control.

1. Initiate scope change requests by completing a scope change request form.
2. Track scope change requests by logging them in a scope change control log.
3. Determine how the scope change will be identified and prioritized.
4. Assess the impact; examine the tasks, schedule, cost, and quality affected by the scope change.
5. Select the recommended solution to the scope change.
6. Meet with the owner to accept or reject the change.
7. Implement the scope changes order, if required, and document the changes.
8. Communicate to the project team so all members understand the affect of the scope change.

A Vision for an Engagement Management Services Organization

I’ve talked about this one before as well as re-iterated my discomfort with having an organization that separates project management completely from the sales or project initiation portion of an engagement. In my opinion it is wrong and it puts not only the PM but the company as a whole behind the 8 ball from the beginning in trying to deliver the right solution to the customer and keep them happy.

Any startup, small or even well established company that is proceeding down the path to a more structured and standardized organization could benefit from this mentality. Project Management needs to be first and foremost in their minds as they work to engage a new project or customer. Nothing bad will come from this early injection of PM, only good will be realized.  PMs or a PMO can provide an organization with proven leadership and defined processes that will help fill the gaps as an organization works to not only acquire new customers  but to really excel in performing for all customers.  The right processes will take an organization from a $50 million company to a $500 million company.  Product excellence and retention of customers is key, and you get there by engaging the right experience early in the process.

What I am really proposing here as an ideal solution is an internal organization that oversees not just Project Management, but the entire delivery process and what that means to various parts of the organization (Sales, Accounting, Legal, IT, etc.).  It would eliminate the surprises that an organization is hit with on a weekly basis because they are still lacking particular structures and defined processes within the Sales to Delivery functionality.

I’ve included below a basic high-level definition of what I see the Engagement Management Services organization to be in a typical company.

Engagement Management Services

Engagement Management is a systematic approach that initiates with the sales process and ends with the engagement closing.  This typically has an accounting component associated with it – overseeing the profitability of project engagements within the organization.

Engagement Management would provide direct oversight of Project Management within the company.  Additionally, it would have touch points with Sales, Legal, Technical Professionals (developers, business analysts, network administrators, etc.), Accounting, and others as necessary.  The processes that Engagement Management follows would support the organization as a whole in delivering products and business capabilities, not just the individual groups.

Project Management is a more narrow focus of providing management of an organization’s projects.  Engagement Management would include Project Management, but would also focus on providing an organization’s enterprise-wide capabilities and services to outside customers and partners in an attempt to increase revenue and profitability while overseeing much of the Sales and other related areas that interact with the project and project teams as well as the customer.

Engagement Management would provide the tie between Sales and the actual technical solution.  It would be the glue that holds the delivery process together with the intent of avoiding many of the disconnects faced by organizations when Sales, IT and PM are all working under their own assumptions and priorities.  Currently, many organizations experience frustrating disconnects between Sales and Delivery.  I’ve been a part of organizations that experience these frustrations on a weekly basis.  An Engagement Management structure would help “standardize” the sales process and how that “sold” solution translates into a “delivery” solution.

A Proposed Organizational Structure

• CEO
  • Sales
  • CIO
    • Technical Staff
  • Engagement Management
    • Project Management Office
  • Operations
  • Etc.

Benefits of an Engagement Management organization:

• Customers see a standardized and professional engagement process across all implementations
• Brings all of PM together and allows for future growth
• Allows for the ability to standardize the PM approach and reporting
• Ability to define standardized PM templates and processes
• Not hindered or biased by a reporting relationship through Operations or IT
• Ability to define a change management process and change order/scope management process
• Engagement Management provides general oversight to all inputs and deliverables in the delivery process
  • Business Requirements Docuement (BRD) delivery and signoff
  • Statement of Work (SOW) delivery and signoff
  • Project Plan/timeframe definition
  • Solution or product implementation
  • Post-implementation reviews
  • Customer satisfaction

In my solution there would still be a PMO led by a PMO Director or at least a structure of PMs leading projects and reporting to a centralized leadership. The Engagement Management Services organization must be led by a very senior individual – preferably a VP.  All PM support personnel would report up through this person’s organization.

Summary

Some organizations are probably doing this now and doing it right. What I’m trying to say here is, if your organization is floundering because of the disconnect between PM and other support organizations, then incorporating an Engagement Management Services type structure to ensure that the proper oversight is given to mission critical engagements may be an answer. It’s frustrating for the customer and for the PMO to continue to deliver projects that are not what the customer wants and not in either organization’s best interests and and to continue to experience issues that could have been avoided had project management been brought into the process at the beginning.

A Quick Guide Project Management Methodology

A few months ago I covered all 8 phases of my general project management methodology over 8 separate and fairly long articles. What I would like to do here is condense them into one – still lengthy – quick guide type article for general reference to anyone who might need it. Let’s get started…

Phase 1 – Project Kickoff

Purpose:

• Onsite meeting with the customer at the beginning of the engagement to review the SOW, the project team, the draft project schedule and milestone dates, and the process for managing the project

Activities:

• Prepare for onsite Kickoff session with customer
• Create/revise draft project schedule
• Create presentation slides for Kickoff session with customer

Deliverables:

• Kickoff session slide deck
• Initial project schedule

Phase 2 – Exploration

Purpose:

• Document business processes, further refine business requirements for the project, work with the customer to detail the difference between the “as-is” processes and the “to-be” processes. Further involvement by customer SMEs will be required.

Activities:

• Create the Business Requirements Document (BRD)
• Customer review and signoff of BRD

Deliverables:

• Business Requirements Document
• Revised project schedule
• Revised issues/risks list
• Weekly status reports
• Weekly status meetings

Phase 3 – Design

Purpose:

• Goal is successful completion and signoff of main Design phase deliverable, the Functional Design Document (FDD)

Activities:

• Work with customer SMEs and delivery team to further refine and finalize functional design requirements, reporting requirements, data migration requirements, data integration requirements, security requirements, etc.

Deliverables:

• Functional Design Document
• Revised project schedule
• Revised issues/risks lists
• Weekly project status reports
• Weekly project status meetings
• Assignment of development team members and other support personnel to the delivery team

Phase 4 – Development

Purpose:

• To develop a workable solution according to customer specs that is ready to move into the Testing phase

Activities:

• Develop a Technical Design Document (TDD) – mainly for use by the delivery team and the technical lead
• Develop the system to customer requirements
• Perform periodic demos or reviews to ensure that the solution is on track

Deliverables:

• Technical Design Document – optionally for the customer
• Periodic development reviews/demos
• Revised project schedule
• Revised issues/risks lists
• Weekly project status reports
• Weekly project status meetings

Phase 5 – Testing

Purpose:

• To ensure that the developed system is tested, matches customer requirements and is bug-free for training and deployment

Activities:

• Define testing approach
• Document Test or QA Plan
• Create test conditions/cases – this should be a customer activity
• Conduct system testing
• Conduct User Acceptance Testing (UAT)

Deliverables:

• Developed system
• QA or Test Plan
• User Acceptance Testing signoff
• Revised project schedule
• Revised issues/risks lists
• Weekly project status reports
• Weekly project status meetings

Phase 6 – Training

Purpose:

• To train the customer or the customer’s trainers on usage of the production-ready system prior to Deployment

Activities:

• Development and delivery of a training plan
• Development and delivery of training materials
• Setup of a training environment or server with a production-ready copy of the system
• Training-specific data loaded to the database
• Delivery of training, or train-the-trainers training

Deliverables:

• Training plan
• Training materials
• Training environment
• Training data in training database
• Revised project schedule
• Revised issues/risks lists
• Weekly project status reports
• Weekly project status meetings

Phase 7 – Deployment

Purpose:

• To implement the tested and production-ready system into the live customer environment and deploy to all relevant users

Activities:

• Setup production environment
• Load production data to the production environment
• Customer review and signoff of go-live readiness

Deliverables:

• Production environment
• Live data load to production environment
• Deployed production-ready system
• Revised project schedule
• Revised issues/risks lists
• Weekly project status reports
• Weekly project status meetings

Phase 8 – Post-Deployment

Purpose:

• To provide the customer with a window of time after go-live where the key delivery team members will still be available to the customer for issues, etc. and for knowledge to be passed on to the on-going support organization

Activities:

• Go-live support for an agreed upon timeframe (30-60 days) by the delivery team for the project
• Hand-off to support team
• Re-connect with the customer team for Lessons Learned sessions

Deliverables:

• 30-60 days of post go-live support by the current delivery team
• Lessons Learned documented and delivered to delivery team, customer team, and support team