What are Some Project Management Best Practices?

Interested in the top 10 project management best practices? 

You’ve come to the right place.

Project management, a discipline within the larger body of management knowledge, concerns projects. Projects are endeavors with a start and an end. In other words, projects are different from ongoing operations.

The Project Management Institute (PMI) defines projects as follows: “It’s a temporary endeavor undertaken to create a unique product, service or result.” PMI then goes on to define project management as follows: “Project management, then, is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.”. Read about these definitions in “What is project management?”.

Project management existed since the earliest human activities. It’s just that it wasn’t named as such back then. Large industrial-scale construction, manufacturing, and transportation projects necessitated a formalized approach, and thus was modern project management born.

Read more about this interesting historical bit about project management in “History of project management”. IT industry took to project management following queues from these other industries.

Down below, we list some of the project management best practices to consider.

IT project management best practice #1: Define project lifecycle and milestones

A project manager needs to define the project approach first. This requires defining the project lifecycle. There is also the need to define project milestones. It’s not enough to just document these in a nice project plan since the project team must know what the project milestones are.

The definition of the project lifecycle varies according to the methodology. For example, the ‘Rational Unified Process’ (RUP) defines the following phases in a project lifecycle:

1. The inception phase: This consists of defining a vision of the end-product and a business case.
2. The elaboration phase: The project team defines the product and baselines the definition. The architecture definition and project planning are also done in this phase.
3. The construction phase: This is when the product is built. In the case of an IT application development, this is typically the development phase.
4. The transition phase: After the product is developed, it’s transitioned to its’ users. In the case of an IT application development project, this phase is the post-deployment transition to users. This typically includes a warranty phase. There are times when the user community needs ongoing maintenance. That typically triggers a separate long-term maintenance engagement, which is also a project but with different scope and timeline.

Read more about the RUP lifecycle phases in “Concepts: project lifecycle, phases, and major milestones”. Other methodologies may define the lifecycle phases differently, however, they still follow this chronological approach.

There is a need to analyze dependencies between different tasks before a PM can decide on milestones. These are typically intuitive.

Get a complimentary discovery call and a free ballpark estimate for your project

Get Started

Trusted by 100x of startups and companies like

E.g., in a large enterprise, an IT application development project following the ‘Waterfall’ methodology will feature dependency between testing and coding, i.e. testing can start only when coding ends. PMs need to pay attention to such basics.

However, the PM must take detailed inputs from all project stakeholders including the project team to determine these dependencies. This ensures thorough project planning.

Read more about setting dependencies and milestones in your project plan in “Milestones, project phases and dependencies”, which explains this using the examples of a PM tool.

Finally, the project lifecycle phases and milestones are meaningless unless the PM communicates, communicates, and further communicates them to all stakeholders! That includes the team.  

Thankfully, there are many modern tools that make this communication easier even if the team isn’t co-located. Examples are Trello, Asana, and Slack. Check our guide “The 10 best Agile project management tools” for more examples.

#2 among project management best practices: Baselining of requirements and project scope

“It’s a small change, just add a drop-down menu for this field. I agree this wasn’t there in the requirement, but hey, this is really minor, isn’t it?” How often do IT PMs and developers hear this from clients? Very often, I am afraid.

Yes, the clients’ success is the project teams’ success. Also, the change may really be minor. We are missing the point here, though!

The client will only be successful if a consistent, rule-driven approach is used for managing projects. Even small changes shouldn’t be pushed through as project scope creep. Clients may have many needs from the project, however, the requirements baselining process will include only those they prioritize enough.

Once it’s done, the project scope is set. Both the client and the project team should maintain the required discipline to adhere to that scope. Read why it’s so important in “Why project scope is so important”.

The PM should regularly review what the project is working on. If it’s outside of the project scope, the PM should question the rationale for that work. A fact of IT development projects is that client project team members and service providers’ development team members often work very closely.

Client team members often bypass the change control process and inject new requirements by directly communicating with the team members. The PM should have regular communication with the client project team to streamline the process and prevent scope creep.

Project management in IT best practice #3: Organization, systems, and roles definition

It’s a non-negotiable PM practice irrespective of the PM methodology. In the traditional waterfall methodology, IT PMs would create a ‘Project Management System Summary’ (PMSS). This is a comprehensive document that defines the project team’s roles and responsibilities and identifies the ‘processes, methods, and tools’ (PM&T) for the project.

Find out more about PMSS in “Project management system: definition & example”.

For example, a PMSS defines roles such as PM, business analyst, developer, tester, and independent quality auditors. It would also identify PM tools for the project, e.g., Jira. Check out “List of 10 best project management software Tools” for more examples.

On the other hand, if a project uses the ‘Agile’ methodology, the roles would be a bit different. While the concept of organizing the project team and PM systems remain the same, the ‘Agile’ methodology focuses more on collaborative development in short iterations with small teams.

Read our guide “How to build an agile development team?”.

PM best practice #4: Quality assurance

First, a clarification. IT project quality assurance (QA) is not just testing. It includes testing, but it encompasses much more than that.

Think of two concepts, i.e. ‘verification’, and ‘validation’. Verification is to check requirements documents, technical specifications, design, test plan, test cases, and the program code. On the other hand, validation is to test whether the software meets the project requirements. An IT project QA must cover both.

Read more about verification and validation in “Difference between verification and validation”.

With advances in technology, there are many automated testing tools available in the market. I recommend using a suitable automated testing tool. There are many advantages, e.g., such tools automate test executions based on test cases using automated scripts.

Tools can also help automate populating test data in test databases. Selenium and Jenkins are examples of such tools, however, there are more.

In the verification domain, PMs need to ensure a review of specifications, design, test cases, test plans, and code. An IT development team should use relevant checklists for these reviews. Checklists can’t be static. They must be regularly updated based on statistical process control and defect management.

Read more about it in “Early defect identification: application of statistical process control methods”.

Defects, when identified early in the project lifecycle, are the least costly. Hence, the development team should try to identify defects in the design phase. If defects remain undetected in the early phases and are found in the later phases such as coding and testing, they are costlier.

To identify defects early, statistical process control of defects, learning lessons from such exercises, and updating review checklists are important.

PM best practice #5: Upholding schedule commitments

An IT project fails often, besides, it’s not just a recent trend. Back in 2009 also, ZDNet had reported that 68% of IT projects fail! Clients are wary, and only when service providers consistently meet milestones can the clients breathe easy.

When scheduled delivery dates are committed in the project plan and communicated to stakeholders, those commitments need to be met.

However, modern IT projects are increasingly complex. Many factors can cause schedule slippage. If a project team doesn’t proactively communicate project status to clients and brings up bad news at the last minute, it will adversely impact the trust.

Hence, IT PMs must regularly talk to team members and remain fully up-to-date about the project status. More importantly, the PM must proactively communicate status and issues to the client. Read why it’s so important in “Project Managers: Don’t underestimate the importance of communication”.

PM best practice #6: Tracking project variance and analyzing them

Project variances are inevitable. While most discussions about IT project variances center on cost and schedule variances, the subject is broader than that.

There are many approaches to calculating project cost and schedule variances, e.g., ‘Earned Value Analysis’ (EVA). They typically focus on the baselined project budgets and calculate variance against that. Likewise, schedule variance is calculated against the baseline project schedule.

Read “Earned value analysis (EVA)” for more details.

IT projects also need to calculate variance against their baselined quality objectives. E.g., the project may have prioritized the ‘delivered defect density’ as a key quality metric.

It’s expressed as the number of defects that went undetected in the end product, divided by the size of the software. The size may be expressed in various terms, for example, total function points delivered, or total man-hours.

The expression of the size depends on the kind of project, e.g., IT maintenance projects often use the total man-hours as the denominator in the equation. PMs need to regularly track project metrics and track whether delivered defect density is more than the defined objective. If it’s more, they need to take corrective actions.

Read more about these metrics in “Defect density“. There could be more quality metrics PMs may want to track, for variance analysis. However, it’s important to declare the list of metrics tracked in the quality plan section of the PMSS.

PM best practice #7: Course correction based on project variance tracking

The findings from the project variance tracking should trigger course correction if the project shows signs of falling short of defined goals. This should be an organic and ongoing activity in a project.

PMs should certainly lead them, however, the best results are only possible with complete participation from the project team. Project teams’ participation increases their stake in project success.

Course corrections could take various forms, however, a ‘lessons learned’ exercise is a common way. Project teams should conduct ‘root cause analysis’ (RCA) for variances. There are tools to conduct RCA, e.g., the ‘Ishikawa Fishbone Diagram’.

Learn more about the fishbone diagram in “Fishbone diagram cause and effect analysis”.

Project teams should identify corrective and preventive actions. They should update project documents such as review checklists and ensure everyone uses the updated documents. Learn more about ‘lessons learned’ exercise in “Why and how to document lessons learned (with bonus lessons learned template)”.

‘Agile’ projects using the ‘Scrum’ technique will need to use the ‘Sprint retrospective meeting’, i.e., a form of lessons-learned exercise. Read more about it in “How to build a scrum development team”.

PM best practice #8: Risks and issues management

Every project including IT projects has risks. Risks are inevitable in any human endeavor. Best PMs proactive identify risks and plan to mitigate or accept them. Accepting risks means a readiness to deal with the impacts if they indeed materialize, hence contingency plans are needed.

Following are a few examples of common risks in IT projects:

• Unfamiliar and untested technology might cause schedule and budget overrun for ‘First of a kind’ (FOAK) projects. Recent examples of such risks materializing are blockchain-crypto ICO projects that could not meet their schedule due to the technology being so new.
• The project may find it hard to onboard skilled developers for niche skills, which may cause project delays.

Modern IT projects use risk assessment and risk management tools. A distinct advantage of such tools is that they accumulate plenty of historical knowledge, thereby, prompting PMs to look at the right places for project risks. Read more about risk management in “Risk assessment in project management”.

Unidentified risks can turn into issues during project execution. Alternatively, issues can occur due to other reasons. Either way, responsive project teams need to address them. IT projects may face issues due to unanticipated client budgetary constraints.

Every client organization has political battles, which may also create new client commitment-related issues for the project. Read more about project issue management in “7 issue management tips”.

#9 among the best project management practices: Project change control

Despite IT project managers implementing project requirements and scope definition best practices, project changes are inevitable. Hence, experienced PMs prepare for it beforehand and create a project change control process.

This might consist of simple documentation explaining what the change is, its’ cost and schedule impact, and why it’s important.

Most important is the diligent implementation of the process. This requires buy-in from clients, hence, the PM must get their commitment to it early in the project lifecycle. PMs must also involve the project team whenever change requests come in, to get estimates for these changes.

PMs must regularly talk to clients in an institutionalized manner to get change control approval. Project plan re-baselining is very important in this project change control process. Finally, communication with all stakeholders about project changes is very important to achieve benefits.

Read more about project change control in “Scope change control”.

Successful project management best practices #10: Stakeholder management

Client organizations aren’t monolithic entities. There are people there and often they come from different functional organizations. Since different client organizations have differing project objectives, each client team member may want to promote their interests.

An Information technology project manager needs to understand the complex interplay between different client stakeholders and navigate that political environment astutely. PMs should work closely with client stakeholders for this and build a lasting relationship.

Stakeholder management impacts far more than the present project. This is a key among project management best practices for the service provider organization to build a long-term foothold in their clients’ organization and gain future business.

Read more about it in “10 key principles of stakeholder engagement”.

Final Thoughts on project management best practices

Efficient and effective project management ensures the success of a software product in a competitive end-user market. These ten project management best practices will help you work out a smooth plan for the software development and deployment process while meeting the stakeholder’s expectations.

Experienced project managers can help a great deal here. They have an idea of the best possible strategy and route to take in particular circumstances. If you don’t find such experienced professionals in your project team, we would advise you to outsource them from a reputed software development agency.

DevTeam.Space is one such platform with field-expert software developers community and project managers. You can easily partner with them for your next project by writing to us your initial specifications via this form, and one of our account managers will get back to you instantly.

Frequently Asked Questions