A Unique Introduction to Microsoft Project®

In this blog we'll look at Microsoft Project® and the unique insights of our course.

Microsoft Project® is one of the most widely used project management software applications. The first version was released in 1984, and it has been a mainstay of project management software since then. Our course provides an overview of the most commonly used features, but this training is exceptional. You will learn how to use Microsoft Project to manage critical activities that make the difference between success and failure.

Microsoft Project overview

Microsoft Project is used to prepare and manage plans. Typical tasks include the following:

·        Prepare a high-level plan.

·        Add activities to the headings in the plan.

·        Assign resources to the activities.

·        Budget management.

·        Analysing resource utilisation.

·        Adding dependencies.

·        Critical path analysis.

·        Reporting progress against the plan.

These topics are included in the course, and you also learn secrets about estimating, agreeing on critical success factors and adding the correct level of contingency.

Microsoft Project Features

Some of the most commonly used features of this application include:

• Gantt charts that provide information on tasks, milestones and dependencies.
• Time management.
• Resource management that shows if tasks have been over- or under-allocated.
• Overview of the roadmap and timeline.
• Task management.
• Standard and customised reporting. 
• A roadmap that supports project portfolio management.
• Team collaboration.
• File sharing.

Microsoft Project Benefits

The application has the following benefits:

• It allows you to manage budgets, timelines and resources effectively.
• The application provides the control required to track and report on progress.
• The ability to add additional columns to a plan for estimating and management. An example of this is adding a column to show effort for a task. This is invaluable when estimating total and individual effort.
• Strong constraint and dependency management capability. 

The objective of project management is to deliver a high-quality project that meets the critical success factors to an agreed budget and timescale.

An IT project manager will use a range of skills, methodologies, and expertise to achieve the project’s delivery in line with the business objectives. One of the responsibilities of a project manager is defining all deliverables and ensuring they are completed to the quality standards and accepted by the stakeholders.

An effective IT project manager needs an understanding of the technology and effective people skills. Furthermore, strong stakeholder management and the ability to support alignment of the project with the organisation’s strategic goals is critical.

Typical project manager roles and responsibilities

A project manager has many responsibilities. This is one of the things that makes this profession so interesting. Microsoft Project or another planning tool will be invaluable in planning and managing a project.

Typical activities include the following:

• Preparing documentation, including the project initiation document, the project plan, the quality assurance document, the dress rehearsal document, the cutover runbook, etc.
• Agreeing critical success factors with the stakeholders.
• Planning and monitoring activities.
• Risk management.
• Managing quality assurance.
• Securing and managing resources. (Including third-party resources.)
• Managing the project budget.
• Managing data quality activities.
• Running dress rehearsals.
• Overall management of test activities.
• Stakeholder management.
• Methodology selection and enhancement.
• Escalating to the project board if required.
• Managing cutover.
• Preparing Go/No Go documentation and managing the Go/No Go meetings.
• Handover to post-go-live support.
• Managing decommissioning of legacy systems.

According to the type of project and organisation, there may be additional responsibilities, but this presents an overview of typical project management responsibilities.

Planning Projects

One of the most important points of the course is that virtually all projects are different and may require a different approach or enhancements to the methodology. These factors will impact how you approach the planning process.

Keep an open mind and don’t be constrained by a methodology. Of course, if you are working in an environment with strict methodology guidelines, please consult with the stakeholders before making any enhancements or changes. However, as a general rule, people care much more about the delivery of quality projects rather than the approach used to deliver them.

To illustrate this principle, we’ll start with a representative Waterfall project.

The standard Waterfall stages are the following:

• Project initiation
• Requirements/analysis
• System design
• Implementation
• Testing
• Deployment
• Maintenance

Overview of preparing a plan for a Waterfall project

The first step is to add the high-level phases to the plan.

To help estimate and manage progress, it is beneficial to add a column to the plan for this information. If you are using Microsoft Project®, add a column, select 'number' as the type and update the name to something like 'Effort (in Days)'.

The same principle applies to other project management tools. The objective is to show the estimated effort associated with the activity.

The following screen shows the duration, effort and dependencies. There are different schools of thought on when dependencies should be added. I recommend adding them at the start of the planning process. This will provide visibility of the impact of the dependencies on the critical path from an early stage in the project.

Critical Activities Regardless of Methodology

Please consider adding the following activities to your plans. They can make the difference between success and failure. The following activities are proven to reduce risk, but some of the activities are not a prominent feature of Agile or Waterfall methodology.

Dress rehearsals

Along with professional project initiation, dress rehearsals are the most critical activity for ensuring a successful project. Dress rehearsals will draw attention to problems not encountered during any test phase. The users will approach go-live with a high level of confidence because they have already completed critical business scenarios in the dress rehearsals.

Dress rehearsals are not a rerun of UAT. They are a separate activity with different objectives.

What are business scenario dress rehearsals?

In this activity, users complete core business processes in an isolated environment to provide the highest level of assurance for cutover and BAU. The business decides on the key business scenarios with advice from the project team, if required.

What are the principles of dress rehearsals? 

• Users run their critical business processes in a dedicated environment to prove readiness for go-live.
• The mindset of the dress rehearsal participants is that this is the first day of go-live.
• The business scenarios are agreed upon, and the users run them exactly as they will in BAU.
• Test scripts are not used. 
• The dress rehearsal sequence is based on business priority and level of risk. The most critical ones are completed first.
• Please note that multiple scenarios may be run in parallel.
• Superusers assist the participants, and the support team is on call in case there are any issues.
• People responsible for the role after go-live should complete the activities in the dress rehearsal.
• She could identify system or data problems that the test phases overlooked.
• Run at least the first week’s BAU activities and additional weeks if possible. (One full month is recommended.)

o   Include any additional priority activities such as critical reports, etc.

• Dress rehearsals are not a rerun of UAT or any other test phase.
• Ideally, production data should be used for the dress rehearsals to ensure data quality and to confirm the validity of the dress rehearsals.
• Run real-life scenarios using live data wherever possible. For example, processing a full day’s worth of transactions.
• Roles and permissions are validated to ensure they will support BAU processing.
• Run integrations using the production schedules and BAU volume data to prove timing.

Strong project governance

Effective governance is critical for successful delivery.

• Ensure appropriate project governance is in place and everyone on the team understands it. This includes the ability to escalate issues and resolve them quickly.

Business process change

• If the programme involves substantial business process change, it must be supported with an analysis of the target operating model, data analysis and mapping, governance and strong leadership.

Benefits management and critical success factors

Agree on the critical success factors at the beginning of the project. This doesn’t need to be a long list. In fact, having five or ten critical success factors keeps the team and stakeholders focused on delivering the most important elements.

Ensure you can measure critical success factors to confirm they have been delivered. It's gratifying to review these after delivery and have stakeholders agree that all priority items were delivered.

Risk management 

Risk management is critical throughout the project and will come under sharp focus as cutover approaches.

Risk management should be based on objective criteria. Without this, individual opinions of the level of risk will vary widely. In the risk management section, we’ll look at a spreadsheet with typical criteria. The Yes or No answers only take a few minutes to complete, and this provides a low, medium or high risk score.

Deliverables

Regardless of methodology, agreeing on and tracking deliverables is key to managing a successful project. Whether it is the deliverable from a sprint in Agile or a milestone in a Waterfall project plan, stakeholders will require updates on progress. Understanding, tracking and managing dependencies between deliverables is essential.

Project initiation

This is a critical activity. Issues with project initiation are a major factor in eighty per cent of failed projects.

The level of documentation depends on the size and complexity of the project. The following items need to be considered:

• The size of the project is a significant consideration. Do you have a development team of five and one stakeholder or ten project teams, 200 IT staff, 50 business people and 20 key stakeholders?
• Does the project have a hard deadline that is not negotiable? For example, is there a critical business requirement that includes supporting a product launch or delivery of a statutory or regulatory project?
• Is additional infrastructure required?
• Are new non-functional requirements included in the project scope? 

The PID usually contains the following sections:

• Background.
• Business case.
• Project definition.
• Project objectives.
• Critical success factors and expected benefits.
• Project methodology.
• Project scope.
• In scope.
• Out of scope.
• Timescales.
• Stage plan.
• Deliverables.
• The project resource responsible for the deliverables.
• Constraints.
• Dependencies.
• Assumptions.
• Quality assurance including quality standards.
• Risk management.
• Test approach.
• Dress rehearsals.
• Cutover planning. 
• Post go-live support. 

Other items may need to be added depending on the type and complexity of the project. Please note that the contents of the PID may vary based on the organisation's standards, the type of project, and the methodology used.

Please include all relevant sections in the project initiation phase, regardless of the methodology used.

Project budget

Please consider the following:

• It’s always beneficial to include contingency in the project budget. 
• Increase the contingency if you have several unknowns.
• Please consider that securing additional budget may not be guaranteed. Many projects have been cancelled due to budget issues.
• Realistic estimates are critical on all projects, but on complex projects it’s worth taking time during initiation to ensure your estimates are as accurate as possible. 
• Some projects include costs for company employees who are seconded to the project, while others do not; please confirm this at the start of the project.
• When preparing budgets, remember that most tasks take twice as long to complete compared to their estimates. 
• Consider the complexity of the critical path of the project.
• How likely are you to have delays where planned work can’t proceed but costs for project staff will be incurred? Also, third-party staff may be impacted by delays, and this could result in extra costs.

Communication plan

On some projects, the activities in the communication plan commence close to going live. The plan should be prepared during the early phases of the project, and communication should be an integral part of the complete project. 

Quality plan and quality assurance 

Quality assurance is a separate activity, and it is essential for successful project delivery.

Be wary if anyone says, ‘Quality assurance is just part of everyone’s activities.’ This statement isn’t correct, but it is heard on many projects. The quality plan should specify the person responsible for quality assurance and measurement criteria.

Quality assurance is required for all activities, but data quality assurance is an area that requires additional diligence. 

Project board

The project board exists to support the project and guarantee proper governance. If the project team is unable to resolve a problem, they should escalate it to the project board.

When attending the project board meetings, you should be very clear about the issues, the impact they have on the project, and the action you are asking the board to take. Please prepare clear and concise reports for the project board according to the agreed schedule.

Estimating

Universities have conducted studies to determine the accuracy of estimates versus actual time taken to complete tasks. They concluded that tasks take, on average, over twice as long to complete compared to the estimates. Optimism, and not considering potential issues and blockers, contribute to the problems with underestimating effort.

The studies found that people are able to estimate other people’s tasks more accurately than their own. Failing to use historic data to assist with estimating is another cause of poor estimating.

Resource planning

It is good practice to assume that a full-time project resource will not be available for more than 80 per cent of the time. This is to account for holidays and illness.

If people are working on the project in addition to their day jobs, ensure there is a contingency plan in case they are needed to resolve urgent BAU issues. These people may be subject matter experts (SMEs), and it may not be easy to identify a replacement for them. 

Work packages

Work packages are a valuable tool to control time and cost. They distil work into an easy-to-understand one-page document that includes resource, cost, date and deliverable information.

Project delivery

Please always remember the famous saying, ‘There are no IT projects, only business projects supported by IT.’ 

Various people have been credited with this statement. The meaning is that there must be a business benefit to any project, or there is no point in the activity. With this in mind, it is important to have a way to show the benefit realisation of the project.

Testing

Allow sufficient time for all test phases in your project plans. Security testing by third parties may have a long lead time, and this activity usually has a number of prerequisites. Please review all the activities and include them in the plans.

A common issue on projects is underestimating test effort or the importance of test phases. On project rescue work, lack of focus on non-functional testing has been an issue. This is a critical test phase; please allow the appropriate level of time and effort in your plans.

Please include specific actions to ensure the test data replicates the To Be production data. This is essential to ensure test validity and readiness for BAU.

Cutover 

Include cutover planning from the start of the project. (Strategy, approach, target dates, etc.)

Develop a detailed cutover plan that includes dependencies, activities, resources, communication, checkpoints and post-go-live project support. Complete a cutover dress rehearsal to ensure that all timings are correct.

Handover to support

Handover to the support team is critical for a smooth cutover. Please include handover activities in all plans. Ensure the handover documentation is fit for purpose.

Review the documentation at regular intervals starting early in the project. Don’t leave the task until the last minute and rush its preparation.

Include the support teams in the dress rehearsals. Add a failure scenario to ensure that everyone from the end user to third-level support understands the process. Furthermore, involve the support team in the preparation of the support service level agreement. (SLA)

Post go-live project support 

Please consider the following in the planning process:

• The timeline that the project team will provide post-go-live support should be agreed upon early.
• From day one of go-live, the support team should take the lead, with the project team assisting them.
• If everything is going very smoothly, the project team may work on other activities, but the go-live support must be their priority.
• Superusers are an integral part of the post-go-live support team. Ensure everyone knows who they are. Having the superusers walk around the departments immediately after cutover works very well.

Summary

Numerous business-critical and technically demanding programmes have proven the effectiveness of the planning, processes and procedures outlined in this article.

Regardless of the size and type of project, I’ve found the following activities essential:

• Dress rehearsals.
• Security.
• Risk management.
• Dependency management.
• Cutover management.
• Cutover runbooks.
• Contingency planning.
• Managing Go/No Go Meetings.
• Post go-live support

The actions work with any methodology and may make the difference between success and failure. They do not feature heavily, if at all, in the main methodologies. Please don’t listen to any methodology purists that resist adding these activities. Waterfall and Agile have been used for decades, but the failure rate for IT projects remains high. As professional project managers, we must do everything possible to reverse this. 

Good luck with your projects! Project management isn’t easy, but it is a worthwhile profession. 

Microsoft Project® is a registered trade mark of Microsoft.