DevTeam.Space Product Development Blog

Explore our in-depth product development tutorials and new technology announcements published by our software development experts

All articles

Project Management: 10 Best Practices

US gross domestic product (GDP) was $1.109 trillion back in 1929 when adjusted for inflation. At the end of 2017, it stood at $18.051. To view of how GDP has grown over the years, read “US GDP by year compared to recessions and events”. This growth has been nothing short of phenomenal.

There are many factors that made this possible. Firstly, it was built off the back of enterprising and hard-working American people. Also, by drawing talent from all over the world has helped massively with wealth-creation too. Policies that favoured wealth creation also played a key part. Another important factor was technological superiority over nearly every other country in the world.

However, one of the unsung heroes to this wealth generation was effective and efficient management.

There are several reasons for management being so overlooked. Mostly, people tend to fixate on technology and innovation, management is considered a stale thing. Whatever be the reason for people overlooking this factor, its role in driving economic progress of the US is undeniable.

The late management guru Peter F. Drucker once said that “management is doing things right”. Read more on his views about management in “The management theory of Peter Drucker“.

It’s self-evident that Americans throughout the decades have been “doing things right”. The market is the best long-term indicator of success, and the American economy is still the largest and one of the fastest-growing in the world.

Project management is simply one discipline within the larger body of knowledge that we call management. It’s important that you manage projects well in your organization, hence, I will show you 10 best practices of project management in this article.

Contents

What is project management?
IT project management best practice #1: Define project lifecycle and milestones
#2 among best practices in project management: Baselining of requirements and project scope
Project management in IT best practice #3: Organization, systems, and roles definition
PM best practice #4: Quality assurance
PM best practice #5: Upholding schedule commitments
PM best practice #6: Tracking project variance and analyzing them
PM best practice #7: Course-correction based on project variance tracking
PM best practice #8: Risks and issues management
#9 among the best practices for project managers: Project change control
Project management best practices #10: Stakeholder management

What is project management?

Let’s define management first. G R Jones defines it in his 1995 book “Organizational Theory” as follows: “Management is the planning, organizing, leading, and controlling of resources to achieve goals effectively and efficiently”. Read more about this definition in “Management: The four functions”.

Project management, a discipline within the larger body of management knowledge, concerns with projects. Projects are endeavours 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 endeavour 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, thus was the 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.

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.

Definition of project lifecycle varies according to the methodology. For e.g., 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 when the product is built. In 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 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 milestones. These are typically intuitive. For e.g., in a large enterprise, 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 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 in 2018” for more examples.

#2 among best practices in project management: 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 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 their project. 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 to 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 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 e.g., a PMSS defines roles such as PM, business analyst, developer, tester, and independent quality auditors. It would also identify PM tools for the project, for 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, ‘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, for 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 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 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 exercise, 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 of calculating project cost and schedule variances, for 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 baselined project schedule. Read “Earned value analysis (EVA)” for more details.

IT projects also need to calculate variance against their baselined quality objectives. For e.g., the project may have prioritized the ‘delivered defect density’ as a key quality metrics. 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 e.g., total function points delivered, or total man-hours.

The expression of the size depends on the kind of project, for 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 this 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 best results are only possible with complete participation from the project team. Project teams’ participation increases their stake in the project success.

Course-corrections could take various forms, however, ‘lessons learned’ exercise is a common way. Project teams should conduct ‘root cause analysis’ (RCA) for variances. There are tools to conduct RCA, for 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 mean a readiness to deal with the impacts if they indeed materialize, hence contingency plans are needed.

Following are 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 delay.

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 best practices for project managers: 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 to all stakeholders about project changes is very important to achieve benefits. Read more about project change control in “Scope change control”.

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 objectives, each client team member may want to promote their interests.

An Information technology project manager needs to understand the complex interplay within 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 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”.