Visual Paradigm logo
Jump to Menu

IT Project Management - Execution & Control Phase

A quick walk-through

The Execution and Control Phase of the IT Project Management Lifecycle

The Execution and Control phase is where the project team build and produce the deliverables required. It begins after the approval of project plans and the allocation of the resources necessary for executing the tasks. During this phase, the project team build the physical project deliverables. The user test and approve the work.

The Execution and Control phase is usually the longest phase in the project management life cycle. This phase ends only when the deliverable has met the customer acceptance criteria established in the project plan and a user acceptance document has been signed off.

Activities and deliverables

The table below lists the major activities of this phase and the deliverables (i.e. process documents) output from the activities.

Activity Description Deliverable
Conduct Execution Kick-off Meeting Conduct a kick-off meeting with all the participants of this phase, to inform the team of the scope and expectation of this phase.
Perform Project Communications Management Communicate project status to stakeholders. Status Report, Meeting Agenda, Meeting Minutes
Manage Project Procurement Document the items procured and keep records for any procurement documents. Procurement Log
Track and Manage Project Risks and Issues Track and manage the project issues and risks identified Risk Register (Updated), Issues Log
Conduct Project Change Management Execute change management process for each of the change requests initiated. Change Control Request, Change Request Log
Accept Project Perform acceptance testing with user and to obtain a formal acceptance sign-off, signifying that the project has met the objectives and requirements. User Acceptance Report

Conduct execution kick-off meeting

Before the team execute any project tasks, a kick-off meeting will be conducted with all the participants of this phase. The meeting focuses project team on the project tasks by re-informing them of the scope and targets of this phase, and this project.

The Execution Kick-off Meeting

Here is the agenda items of a typical execution kick-off meeting:

  • Introduction of participants: A brief introduction of the project team and the parties that are involved in the project. Describe their role and responsibilities in brief.
  • Articulate the duration of phase: Make sure everyone is clear about the start and end date of this phase.
  • Inform the team of expectations: Set the rules and guidelines for this phase. Inform the team of the expectations. For example, ask the team to forward any outgoing emails to the project manager.
  • Discuss Communications Plan: Study and discuss Communications Plan developed in the Planning phase. Make sure everyone is clear about how information is to be collected, formalized and delivered, and in what frequency. Also let them know about the arrangement of regular meetings like daily stand up meeting, weekly progress meeting, etc.
  • Discuss how issues and conflicts should be handled: Have the team understand and agree on how issues and conflicts will be handled. Define the escalation procedure according to the governance structure and approach specified in Project Charter.
  • Discuss working style: Discuss the working style of different stakeholders. For example, whenever the project manager is not in the office, team members can reach him by mobile phone, for urgent issues.
  • Remind the team of any policies, regulations and security considerations that have to be aware of: To protect the work or any information from being leaked, make sure the whole team has thorough understanding on all the organization policies, regulations and any other security considerations say, it is not allowed to store any kind of project -related files in a removable drive.
  • Q&A: Answer any questions that the participants may have.

Perform project communications management

An important activity of this phase is to keep all appropriate parties informed of the project's progress, by sending them a status report. This involves collecting information about project status, consolidating and formulating the information, producing status reports and sending them to the appropriate stakeholders, following the Communications Plan developed in the Planning phase. Regular team meetings are typical sources of project status.

A status report is an important means of regular communication of the progress and status of a project. A typical status report consists of two parts: Project status and deliverable status.

Project status oversees the progress of the whole project. It consists of the parts below:

  • Project status summary, which highlights anything specific which should be brought to attention. It should be at high level so it should not get too much into the details of the project.
  • Weekly accomplishment, which provides a highlight of work performed and milestones and/or deliverables met during the past week
  • Upcoming activities, which provide an overview of the work to be performed/completed in next week and any upcoming milestones or deliverables required to be satisfied.
  • Open issues, list the unsolved issues along with their status.
  • Open risks, list the risks which have occurred, or are on the verge of occurring.

The second part of the status report focuses on reporting the status of individual deliverable, which involves:

  • Forecasted time of completion. Although there's a planned time of completion for each deliverable, it's quite likely that the final product will be delivered earlier or later than the planned time, due to different un-predictable factors. The forecasted time of completion is an estimation made and updated based on the latest situations.
  • Status, which is a description of the status of completion of the deliverable.

Manage project procurement

Procurement Management

This activity involves management the procurement of goods and services in supporting the project tasks. It consists of three main parts.

  • Choose a vendor: Choose a vendor according to the method and criteria documented in the Project Procurement Plan. It is important to ensure that the process of selection is fair and the quality of goods and service are acceptable.
  • Execute the procurement: Purchase the goods and services. Take necessary measures to ensure that the agreed amount of goods or services are delivered on time and meet the level of quality agreed upon.
  • Log the procurement: log each of the procurement activities. For each transaction, provide information about the transaction and store the related and supporting documents in the Project Management Repository. (e.g. signed contracts, purchase orders, statements of work)
  • Track and manage project risks and issues

    Track and manage project risks and issues

    Risk management, is an essential part of the IT Project Management Lifecycle. Managing risks appropriately ensures that your project will stay on track and on budget. In the Planning phase, a Risk Management Plan was developed. This phase focuses on executing the resolution and mitigation strategies planned, monitoring the project for the occurrences of risks, and to keep updating the Risk Register by including any newly identified risks.

    Besides, organize, maintain and track the issues arise during project execution. Ensure that each issue is resolved without much impact to the project's performance.

    Risk management

    The Risk Register is a log of all identified risks. It shows the probability and impact of the risks to the project, mitigation strategy, and when the risk is estimated to occur. The document was developed in the Planning phase, and keep updated throughout the Execution and Control phase with the risks identified during the execution of project activities. It consists of the elements below:

    • Affected Work Packages, which are the work packages that will be affected if the risk occurs.
    • Probability: The chance that a risk will occur, on a scale from 0 to 10.
    • Impact: The impact of the risk on the project, again, scale from 0 to 10.
    • Risk Score: A number that determines the severity of risk, obtained by multiplying the value of probability and impact.
    • Risk Management Approach/Mitigation Actions: The action to take to resolve or mitigate the risks.
    • Early Warning Signs/Trigger: Something which indicates that a risk is about to occur or has already occurred.

    Issue management

    An issue log is used to track, document, and report issues that are identified during project execution. It consists of the elements below:

    • Affected Work Package(s), which are work packages affected by the issue, or the source of issue.
    • Urgency: The urgency of getting the issue resolved.
    • Resolution: The action taken to address and resolve the issue.
    • Status: The status of issue. Typical status include New, Open, In Progress, Fixed, Resolved and Won't Fix.
    • Reported Date: The date the issue was reported.
    • Close Date: The date the issue was closed.

    Conduct Project Change Management

    A change request arises when someone wants a change to the agreed-upon project baseline or deliverables for a project. It can pertain to project, product, documents, requirements, or any other control items identified and documented under the Change and Configuration Management Plan. Upon completion, the request is submitted to the Change Control Board or other similar body for review and approval.

    In the Planning phase, both the management of Change control and configuration management control have been planned. This phase involves processing the change requests following the procedure planned, documenting the result of the change request review and executing the change, if a request is approved.

    The change request log maintains a list of all change requests submitted with summaries to the dispositions and justifications. Here are the elements of a Change Request Log.

    • Title of Request, which is A brief summary of change request.
    • Date of Initiation: The date when the change was initiated.
    • Initiator: The person who initiated the change request.
    • Disposition: Whether the change is approved, rejected or deferred.
    • Justification: The Change Control Board provides a justification for the change request disposition.
    • Changes Summary: The changes and the actions to take as a result of an approved change. Typical changes include additional project effort, cost, schedule, and resources.

    Accept project

    The final activity of this phase is to have the user accept the project. When the deliverables are developed, the user will evaluate whether the deliverables satisfy the requirements. This may also be done by an independent IV&V reviewer, according to the Quality and IV&V plan performed in the Planning Phase. The user or the IV&V reviewer will assess the success criteria identified in the Project Charter, and the acceptance criteria documented in the Project Performance Plan, in judging project success. Finally, document the result of evaluation, sign-off by the user and project sponsor and any related parties like the IV&V reviewer. This concludes that the project has met the goals established.



    Turn every software project into a successful one.