Lesson No. 3: Choose the Simple Over the Complex

Lets take the example of an electric cooker. Something that can cook every dish possible (hypothetically of course). If I were to say, the cooker has a button to set the time you want to cook the food. Each click of the button adds 30 seconds of cooking time. So, to melt butter you press the button 2 times and to boil milk 4 times and so on. Do you really think the manufacturing team will sign-off on such a design?

The response I probably will get is “The design is too simple, there are no awesome features.” But, the fact is, the cooker has all features. It can cook anything. All the cook has to do is, know the right amount of time to cook each dish in our cooker. If this product were to come in the market, it will probably have atleast a dozen buttons with options to cook individual dishes like “one button for cooking rice”, “one button for roasting chicken” etc…

Can you guess what I am coming to here? Imagine how easy it would be to manufacture and maintain the cooker with just one button, as compared to one with 20 buttons. Isnt it?

Computer Software generally solves complex problems. The question is how much of that inherent complexity are you forcing onto the end-user? Is your software amplifying the complexity?

Good Software is something that must absorb the complexity and make the life of a user as simple as possible, instead of further complicating it.

As a software project manager, are you a complexity absorber or a complexity amplifier? The best ones absorb complexity from all sides; from the programmers, from the end-users, from management etc and never amplify it. As the end-users generate seemingly contradictory requirements, your job is to help clean them up, rather than passing them blindly on to the developers. As the developers cite possible technical reasons for not being able to fulfill a requirement, your job is to translate (absorb) that complexity and present the end-users with enough information to help them choose a different option.

How easy is it to use your application? How easy is it to add a new feature to your application? How easy is it to request a new feature? Report a bug? Deploy a new version? Roll back a bad version? For almost all these questions, your answer will be “A bit complicated I guess. It involves a lot of work and processes”. I am not against processes. Processes make our lives easier but the simpler the processes are, our lives become even easier.

Simplicity doesn't happen accidentally. It needs to be actively cultivated. Complexity is what happens when you aren't paying attention.

Are you a manager who pays attention to whats happening in his project? I sure hope you are :-)

Lesson No. 2: Make Project Sponsors Write Their Own Requirements

Before we begin on this topic, doesn’t the title seem impossible? Do you really think the Project Sponsors (Senior Business Managers and others high up in the corporate food-chain) will spend time writing requirements? If you arent sure, just keep thinking in the background and we will get to it pretty soon before we end this chapter.

In any country, any industry, the key reason for project failure is “Poor Requirements Definition” Though PMI recommends a clear and well defined requirements gathering phase as a mandatory part of any project’s lifecycle, in real life, that is rarely the case. In real life, teams are asked to begin development even before the preliminary or rough specs are signed-off.

The companies that are most at risk are those with poor business analysis capabilities. When specifically reporting on technology projects, such as software development, success is categorized, euphemistically, as "improbable." This result shows how difficult it is to find, identify, and define true requirements for a software project.

The software project manager usually does not have the authority or the time to find, select, and prioritize the project requirements on their own, especially since there may be several interest groups involved in the project that probably have conflicting ideas about what they envision the software will do upon completion.

It's up to the project manager to spend time with those who are funding the software project to help them define exactly what they want before the project starts. Is it more important that it is done quickly, with few bugs, or on as small a budget as possible? You can't have it all. What resources and skill sets are crucial to create the software they want? Are they making these resources available to the team?

Without serious, specific consideration of what is to be created on this project during the requirement definition phase, the success of the project is severely under question. Remember, project owners need to convey what they want this software to do, not how the programmers will go about producing that result.

Go back to the first paragraph of this post and re-read it. If you are someone with that kind of doubt, then you need to read the subsequent two paragraphs as well.

Convince the project owners that they must be involved in the process from start to finish. Solid requirements planning establishes a clear connection between the business case, project goals, and the project outcome. Otherwise, the project cannot produce the satisfactory result they are expecting.

A failed software project hurts the project owners most, since they have put up the money to fund the project and were expecting to use the software to earn back their investment.

So, if you want to be a good manager and a successful one too, try to convince your project sponsors to take part in defining/baselining the project requirements. This will eliminate undue surprises

Previous: Lesson No. 1

Chapter 33: The Closing Process Group

Aim: To understand the below two processes in the Closing Process Group
• Close Project or Phase
• Close Procurements

Look at it from this perspective; if you would have known everything that you know today about your project(s) when you started, would you have done things the same way? Would you have used the same resources?

Of course, probably by now you are thinking, what a crock, we are not born experts. How am I supposed to know when to do what and how to avoid execution problems? This is where trusted consultants and an experienced project manager come into play; they help in identifying what pitfalls to avoid.

One of the key recurring messages of the PMI methodology is to leverage expert resources and to use the project archives; executing the proper closing process ensures that the groundwork for your own internal expert resource and knowledge base is built combining knowledge and experience of your people, culture, and enterprise.
This process takes into account the needs for documentation and the understanding of the associated risks, the risks analysis techniques, and the decision-making process.

Exam Trivia:

What is a project deliverable? A project deliverable is the specific, quantifiable product or service that is attained after the completion of a project phase or the project.

The table below shows the inputs, tools and techniques, and outputs for the close project or phase process.

Close Project or Phase
Inputs	Tools & Techniques	Outputs
Project management plan Accepted deliverables Organizational process assets	Expert judgment	Final product, service, or result transition Organizational process assets updates

The key input elements for the close project or phase are
• Project management plan
• Accepted deliverables

Exam Trivia:

For the PMP Exam, you must remember that the close project or phase process and close procurements process are both processes of the closing process group and that the close procurements process happens before the close project or phase process.

Why have these been designated as key input elements? The intent is to take this time to verify that all of the project deliverables are met. Use the work breakdown structure (WBS), the work packages, and the packages’ resource assignments as a roadmap to identify any remaining critical work elements to be completed and ensure the proper transitions.

If there are any unfinished tasks, you need to make arrangements to prepare their termination plan and measure their combined risk materiality to the long term viability of the project, services, and deliverables.

For example, one of the contracts calls for the return of all graphite composite containers to the lease company within 30 days of project completion. Your job as project manager is to issue all the proper closeout work orders and see that these containers are returned to the provider on time. Does this task have anything to do with the long-term functionality of your project? Probably not. However, if not addressed by the deadline, it has the potential of affecting your company at a potentially high annual cost.

This process must be repeated throughout the entire work package dictionary to ensure that deliverables are in line with the project and the performance metrics that you assigned to the service provider.
One of the most important realizations of the project management process should be that the project does not stop when the end is in sight or the product or services are delivered. If anything, this is where you need to concentrate and make sure that all tasks and their peripheral activities are completed. Examples of some of these activities are

• Client or user final acceptance
• Updates to all pertaining historical records
• Transitions to ongoing support
• Release all project resources
• Get final signoff and release from the project sponsor

To know more about the Close Project or Phase process Click Here

Close Procurements

At project build-up, you might have been faced with the need to have extra capacity by bringing in external resources. The close procurements process is the place where you accept delivery of the product and close the corresponding procurement agreements.
For example, you work for a multinational company that decides to leverage its internal expertise in building bridges over long water bodies by combining the resources from the steel and cement business units with its engineering unit. In addition to coordinating the building of the bridge, you are now faced with the challenge of having to orchestrate all the intercompany contracts, expenses, and revenue-generating models in order to ensure the proper level of synergies.

Not that this is any different than using external resources; however, you need to pay close attention to the human factor. The human factor refers to any cultural and personal differences between your culture and the inbound resources.

Another example for contract management might include a combination of internal, external, and outsourced relationships. These relationships might call for a different set of closing instructions that depend on the type of relationship. For example, relationships that exist within a single organization are different from outsourced relationships. Likewise, closing procedures are apt to be different.

The table below shows the inputs, tools and techniques, and outputs for the close procurements process.

Close Procurements
Inputs	Tools & Techniques	Outputs
Project management plan Procurement documentation	Procurement audits Negotiated settlements Records management system	Closed procurements Organizational process assets updates

As per the PMI methodology, the formal outputs of the close procurements process are
• Closed procurements
• Organizational process assets (updates)

Of course, this also means that you are part of the contract negotiation and interpretation, thus requiring a special dose of leadership and management techniques in an environment with multiple moving parts.

For closing procurements, you need to be well aware of your vendor’s or provider’s

• Performance metrics
• Assigned work packages
• Deliverables
• Schedule performance
• Quality control metrics
• If applicable, inspection reports pertaining to regulatory requirements

In addition, you need to address items such as

• Considerations to perform product or service verification that ensures all work was completed in accordance to the service level agreements (SLA) and the deliverables specified in the contract
• Review of contract terms and conditions in the event that the product is not delivered to specifications
• Enabling of early terminations clauses and remediation due to the vendor’s inability to deliver the product, agreed budget being exceeded, or failure to assign the required resources

Exam Trivia:

Early contract terminations can be a result of a mutual agreement or due to a failure to fulfill the contract deliverables. Early termination can occur at any time during the project.

To know more about the Procurement Closure process Click Here

Closing a Project or Phase Criteria

Everyone hopes for a successful project completion, but the cold hard reality is that on occasion some projects are presented with challenges from their inception up to their ultimate demise. Some of the outside reasons that can trigger an early termination could be linked to elements such as

• Market conditions— Where the company or client is forced to discontinue a project simply because the initiative is no longer in line with their long-term market share or presence objectives.
• Customer requirements— Your client decided to implement changes that are well beyond the capabilities of the current initiative, making it cost prohibitive to tackle the project at this time.
• Insufficient resources— You do not have the people, money, facilities, supplies, and so on to complete a project.
• Technical problems— In the project management arena technical problems go beyond the computer. Technical problems could include things such as variances in the density of the material used in a building to the inability to devise a way to hold the insulation in the space shuttle main fuel tank.
• Enterprise culture— The project and its product or services contradict the culture of the company. For example, a company is known for its face-to-face customer service practices and, after implementing a test of self-service point-of-sale checkout lines, discovers that implementing this initiative has a direct impact on the customer perception.
• Bankruptcy— Your client or company will not gain a cash position or additional market share by implementing your project, so the project is cancelled.

Even in these instances, you must ensure a successful transition by leading your project toward project closing criteria elements, which include

• The formal acceptance of the project results or product by your customer
• Documentation and forms resulting from organizational requirements
• Project performance metrics and reports
• Budget expenditures
• Cost benefit metrics and verifications
• Lessons learned

Think of the project closing criteria as those elements that give reasonable assurance that your project took into account the initial deliverables, the client, and the sponsor approval.
In addition, this process works closely with the communication management and the procurement management plans to formalize the ending of your project.

Some of the key participants of this process are

• Project sponsor— This is who gives final validation that the project’s services and products are inline with the original objectives and deliverables of the project before the official hand-off to the client and the operational support team takes place.
• Project manager— This is who keeps coordinating the execution of the communication, procurement, human resources, cost management, and quality plans until such time that the project is officially closed and turns over all the archives.
• Team members— These are the people who assist the project manager in performing the aforementioned tasks, plus assist in transitioning the new product or service to operational support.
• Quality assurance team— These are the people who ensure that all work adheres to agreed project quality expectations and deliverables.

Exam Trivia:

Formal acceptance is the binding process between the customer and the seller (provider) of the product or services that the product or service has been accepted. Its form and contents are predicated by the service agreement or negotiated in the contract.

The key item to remember when preparing for closing a project or phase is that the actual project criteria plan and requirement definition began the day that the project charter and the project scope were defined and agreed upon by the client, sponsor, and the entire project team.

You are just making sure that there is an effective transition between what was agreed upon at the beginning of the project and what was delivered and accepted by the client.

Lessons Learned

Contrary to popular practice, lessons learned should be part of all phases of your project and recorded as they occur; do not get this confused with the post-mortem connotation used by some project managers. If you follow this approach, you might miss the opportunity to write down important elements that might prove essential in future projects.

Why make lessons learned throughout the project? An out-of-context example would be not writing down the license plate and color of a car involved in a hit and run; the more time that passes, the less clarity you have about the details.
The main intent of the lessons learned is to help build an information store that allows anyone in your company to look back in time and understand the decisions made and the circumstances that surrounded the decision-making process.

Some of the triggering events for lessons learned records are

• Significant course corrections are implemented
• Corrective or preventive actions are taken
• Scope changing events occurs
• Root cause for variances between planned and actual project events

It is incumbent upon you to make every effort to be extremely honest and include items that performed well and those that did not. You must highlight individuals involved in the process and the risk factors considered at the time of making the decision.
Some of the elements this report might have are

• Executive summary
• Project phase
• Related work package
• Event description
• Event duration
• Action taken
• Decision makers
• Results
• Areas of improvement
• Time stamp

Exam Trivia:

Do not make the mistake of confusing a project execution satisfaction survey with a lessons learned document—they have different functions.

In addition to recording lessons learned, you must make every effort to collect any evidence and include it as part of the project archive.

Ending a Procurement or a Project

Ending a procurement is not the same as ending the project. There might be cases where they coincide but that is not to be expected as the normal behavior. You could have a case where a contract for a service ends but the project continues with another provider or project phase.

In contract execution, there are two actors: the buyer of goods and services and the seller of those goods and services. During the life of the project, contracts might end for one of the following reasons:

• Successful completion— Successful completion occurs when goods and services have been delivered in accordance with the contract specifications. At this point no further action is required with exception of formal acceptance of the product or services and final payment.
• Collective agreement— This occurs when both parties agree to end the contract. A collective agreement or mutual consent termination allows you to present and negotiate contract closing terms, such as a no-cost settlement, payment of all fees and charges accrued prior to the effectiveness of the cancellation, and payment at a reduced cost by settlement.

For the most part, the parameters of what is available as recourse is specified in the contract by the paragraph that reads something such as, “This agreement may be terminated by either party at the renewal/anniversary date by giving the other party notice at least 15 days prior to the renewal/anniversary date of the Term. This Agreement may also be suspended or terminated by....”

And, you must issue your collective agreement notice for cancellation of services with something such as, “Pursuant to the termination section of the professional services agreement between client and provider, this contract is hereby terminated effective on dd-mm-yy. You are directed to cease all work upon presentment of this notice and start the close procurement process,” (which you need to have defined by now).

When there is a breach— A breach of contract states that one of the parties is not complying with the terms and specifications of the contract. A breach of contract or contract default situation requires immediate and special attention from the legal counsel. Remember that the actions to take are as varied as the different clauses stipulated in the contract.

In addition, because good providers are difficult to find, executing a breach of contract procedure should be viewed as the last resort. Of course, it all depends on your long-term objectives with the relationship and the provider’s willingness to solve the problem that caused the breach. For example, if the default occurs at the service level agreement (SLA) level, your contract might allow you to consider mitigating factors and make adjustments to the SLA. Or, you might be able to outsource, supplement, or augment the function in question at the provider’s expense in order to deliver according to the SLAs.
Another key element to consider is a cure or remediation period. Basically, this is a cooling-off period that allows the provider a pre-ordinate amount of time to remediate the problem before taking any actions.

For contracts where the deliverables, products, and services go according to the plan, the next step is to ensure that

• All issues have been resolved.
• All contract deliverables have been delivered and accepted by the client and the sponsor.
• The project manager gives final approval.
• All assets have been accounted for.
• Final payment has been issued.

Project contracts rarely go beyond the actual life of the project; project phases might end several times throughout the project but there is only one project closing.

Some of the reasons a project might conclude are

• The company loses interest in the project and its deliverables.
• The company, project, or group is replaced or displaced.
• The project comes to a normal end after all the products and services are delivered.
• The project becomes its own organization living beyond the end date as an organizational process.
• The project is replaced by another initiative.

Exam Trivia:

For test purposes, you need to be familiar with project conclusion states such as extinction, inclusion, integration, starvation, addition, collapse, absorption, and deterioration.

Another element to consider when processing a project closing is what to do with the team that was assigned to your project. A project might end, or terminate, in one of several states.

• A project that ends in integration mode has its resources assigned to other areas and integrated into the normal operations of the business. Most often they are reintegrated to the department or group from which they came.
One challenge to this project ending mode is that the responsibilities of the position could have been reassigned or replaced by new processes. This gives the returning team member the special opportunity to flex her muscles and take on new and more demanding responsibilities.
• A project that ends in extinction or collapsed mode is a project that has ended before meeting its stated objectives. Simply stated, in this situation people do not have a place to which to return.
• A project that ends in inclusion, absorption, or addition mode is a project that has been accepted and has transitioned to be part of the organization. In this type of project ending, your team members keep performing their assigned project functions as their new day-to-day responsibilities, maintaining the project performance in accordance to specifications.
• A project that ends in starvation or deterioration mode is a project for which all its resources have been cut. You just have an empty shell.

Note
From the process group perspective, closing a contract is part of the project procurement management process and closing the project is part of the project integration.

Final Review Meetings

At this point, you have received final approval from the client and the sponsor, compiled the final set of reports, released all your team members, and delivered the project products and services. Your next task is to meet with the project sponsor for the final review meeting. This meeting is where the project manager gets final release, receives project performance reports, and is able to return to the bench to wait for the next assignment.

The bench could be going back to your regular job or actually sitting in your company’s project management office to oversee the final archiving steps and get a new assignment altogether.

To know more about the final things to be done while closing the project Click Here

Prev: Chapter 32

Next: Chapter 34

Project Closing

The following are the important themes you must remember from the PMI Perspective regarding the Project Closing Phase.

1. Administrative closeout includes the updating and finalization of all project related documents and records.
2. The goal of a procurement audit is to review the successes and failures of the procurement process in order to transfer the knowledge gained to other procurements.
3. The requirements for formal contract closeout are defined in the contract terms and conditions.
4. The person responsible for contract administration should provide formal acceptance to the seller in writing.
5. The criteria necessary to ensure project closure are formal customer acceptance and meeting the requirements of the delivering organization.
6. Lessons learned should be documented throughout the project lifecycle.
7. Administrative closure should be performed at the end of each phase in a project.

Exam Trivia:
In practical project management scenarios, if the customer is not fully satisfied with the end product that is delivered, the manager and the project executing organization expects us to deliver what the customer wants. But, as per PMI, if the team delivers everything that is present in the approved Scope Statement, then our work is over and the Customer has no right to demand any changes during project closure. So, if you spot such a question in the exam, remember that you cannot take up additional changes to the project scope even though that is not what you would do in real life.

Other PMI Themes:

General PMI Themes
Project Framework
Project Initiation
Project Planning
Project Execution
Project Monitoring & Controlling
Ethics & Professional Responsibility

Chapter 93: The Finishing Touch

We are almost done with our responsibilities as the project manager. The last few things we may have to do are explained in this chapter.

Reviewing the Project

Part of the details of project closure is to analyze project success or failure. You can accomplish this by collecting and generating project evaluation information, such as what went well and what did not. Some of this information already exists in the work performance reports. However, the final information can be gathered in various ways, such as a post-project review meeting with the team or a survey questionnaire. The most important output and the whole purpose of the review is the lessons learned. The review should be comprehensive and should cover the following:

• Both technical and nontechnical components
• Both positive and negative aspects, the things that went well and the things that did not go well
• All stages and phases of the project

Trivia:
The purpose of the post-project review, also called the post-project assessment, is to learn lessons that can be applied to future projects to run them more effectively. It can easily become a finger pointing game in case of projects that had some troubled times. Make sure you don't let such a thing happen during the final meeting.

As part of the project review, you should also measure customer satisfaction from the customer feedback collected by using techniques such as interviews and surveys. This will help the organization establish and maintain a long term relationship with the customer. An example of a survey is a 360-degree survey, which means feedback from all kinds of stakeholders in the project. In general, a 360-degree survey contains feedback from all around the entity being evaluated.

The findings of the review should be recorded in a document that might have different names in different organizations, such as the post-project review report or the project assessment report. Your organization might even have a template or standard for such a report. Depending upon the size of the project, the review report might be part of the project closure report or a separate report. The report will be distributed among the stakeholders and will be added to the project archive. The project closure report can also include the final project performance as compared to the baselines, as well as a description of the final project product.

Releasing the Resources

For effective and efficient use of the organization’s resources, it is imperative that they be released in an efficient and proper manner. The release procedure might be included in the resource planning stage itself, the staff management plan should address the issue of releasing the human resources. Well-planned release or transfer of team members reflects managerial professionalism, which requires that employees be treated with respect and dignity. By ensuring a well-planned release and a smooth transition to other projects, you are helping the employees focus wholeheartedly on the project toward the very end, rather than worrying about the next assignment. This will obviously improve the productivity of team members and the efficiency of the project. Following are some suggestions to consider for properly releasing human resources:

• Although it is possible that different team members will be released at different times, at the project closure you should organize some closure event to honor and thank the project team members, including the contractors, for their contributions. However, you must check your company policy regarding including contractors in company-sponsored events and giving them rewards.
• Plan ahead and do not wait until the last minute. Communicate with the functional manager ahead of time about when a staff member is going to be released.
• Work closely with your organization’s human resources department, which might have some guidelines or procedures that you need to follow.
• Write recommendation letters for team members who have made outstanding contributions to the project.
• Make sure you gather feedback from members who are leaving the team. It will help you develop yourself as a better manager. Never ignore negative comments.
• Don't victimize the person leaving the team. In most organizations, during appraisals, the person who is leaving the team is usually given bad ratings at the expense of the ones in the team. The rationale may be that, I am forced to give bad ratings to a few people because of curve fitting and in the best interest of the project I am retaining the better rating for the person who is actually working in this project than someone who just left or will be leaving in the next few days. This is bad or unprofessional behavior on your part as the project manager.

Once all the closure tasks are completed and the documents are finalized, the project might need to be turned over to another group in the organization; for example, to the maintenance or support group.

Saying Goodbye: The Project Turnover

Depending upon the project, you might need to coordinate the turnover of the project deliverables to the customer or to another group in your organization, such as maintenance or support group. The turnover requirements, such as training help-desk employees, should have been included in the project management plan.

Once you do this, you are no longer in-charge of this project. A feeling of accomplishment for you and your team. This is the time to take your project team and celebrate.

Let the celebrations begin!!!

Prev: Procurement Closure

Next: Summary - Project Closure