Project management is one of the most important and durable job disciplines in the IT industry. To understand why, it is helpful to review the definition of a project – a temporary endeavor undertaken to create a unique product, service or result. Project management is the discipline of orchestrating change. Project management, then, is the application of knowledge, skills, tools and techniques to project activities to fulfill the project requirements. Driving change is even more important today than it has ever been with the pace of technological, business and environmental changes accelerating at a seemingly endless rate.

The chaos all this change creates can not only be overwhelming to manage but also it causes an organization to be vulnerable to considerable risk that must be managed. Despite all the changes occurring, the importance of skilled project managers and sound project-management methodologies have remained constant, enabling organizations to embrace changes in their environments, respond to opportunities/threats and evolve products/services and processes, safely and effectively.

Project management, like any discipline in modern business and technology fields, has changed since 2009 – responding to a more rapid pace of business, embracing modern technology and finding new and innovative ways to address risk and ambiguity. Project-management best practices and new ways of working have emerged as responses to issues, such as compliance, globalization, cloud services, consumerization of IT and agile software development. These provide project managers and project teams with a greater variety of tools they can apply to individual project scenarios.

hero image bcd3e46c

Best practices for selecting a project-management approach

Project management isn’t a one-size-fits-all discipline, even within a single company. Projects have differing needs, constraints and contexts, which must be considered when selecting a project-management approach. There are many methodologies project managers can choose (waterfall, agile, rolling wave, big bang, phased delivery, etc.). Selecting the most appropriate approach is the first step to achieving project success.

Some companies have defined project-management standards, which may constrain the project manager’s options; however, even within the context of these organizations, project managers often have some level of flexibility to make adaptations within a standard to address the project’s unique needs. A seasoned project manager will consider many factors when selecting a methodology for a project. Some of the most important factors include:

Project scale

Large projects often require greater project management rigor and formality to separate and manage project complexity than small, simple projects.

Scope ambiguity

Projects with a clearly defined scope are often better suited for waterfall-type methodologies. Projects with large degrees of scope ambiguity are often more easily managed with agile and rolling-wave approaches, which defer many decisions until later during the project lifecycle when greater scope clarity can be achieved.

Risk tolerance

The impact of project failure on an organization is probably the most important consideration when choosing a project management methodology. If a company’s viability or reputation is at risk or if the product could put lives at risk, then project managers should select project management methodologies that focus on rigor, quality and structured-risk management.

Compliance and documentation requirements

Some projects have regulatory-compliance requirements that mandate a certain level of project formality, documentation and decision governance. Agile methodologies that empower individual team members to move quickly and encourage risk-taking may not be appropriate for such projects.

Culture and experience of the project team

The dynamics of the project team itself may also be a factor in the approach selection. Project teams that have been working together and have established work methods may be more successful continuing to use existing working methods rather than introducing a new project management methodology.

There is no right or perfect answer to what project-management method is best suited for a specific project. Experienced project managers weigh many factors, some internal and some external, to assess the project needs, constraints and environment to select the methodology they think will maximize the success of the project.

Project-management standards

Project management has existed for centuries in various forms but became a distinct profession during the mid-20th century. During the past 60+ years, the Project Management Institute (PMI) has emerged as the leading professional organization promoting standards and best practices in the project management field. PMI has developed a comprehensive ecosystem of project management resources, including A Guide to the Project Management Body of Knowledge (PMBOK) and the globally recognized Project Management Professional (PMP) certification. In addition to its core project-management products, PMI has developed variants for program management, portfolio management and agile methods as well as specialty disciplines, such as business analysis, risk and scheduling.

Because of its storied history, broad coverage of project management-related topics and the global ecosystem of project management professionals and software vendors aligned to PMI’s standards, PMI is one of the industry’s leading sources of project management best practices and defines project management in the context of 5 process groups:

Project management best practices strive to execute these processes effectively and efficiently to achieve any project’s objectives. In addition to the process areas, PMI defines 10 project management knowledge areas, which provide further clarity about how to execute and apply the project-management processes within the context of a project.

It is within the context of these knowledge areas that most project-management best practices have emerged. The core project-management processes are the same, regardless of the nature of the project or methodology selected. How you execute the processes is a matter of subjective decisions made in each of the knowledge areas.

Best practices for project charters

The project charter is arguably the single, most important project-management artifact – yet most projects proceed without a clearly defined charter, leading to a host of problems later during delivery. As one might imagine from the name, the primary stated goal of the project charter is to grant authority to the project and project manager to drive change on behalf of the organization. This is important because it establishes the legitimacy of the project effort and serves as a foundation for developing support for the project across an organization.

The value of the project charter does not end with establishing the authority of the project manager and project team. A clear project charter provides clarity of the project scope, timelines and constraints, which can serve as the basis for project planning and to avoid potential confusion about what changes the project is expected to influence.

Avoiding conflict

Having the project scope clearly defined in the project charter helps avoid conflict amongst project team members and stakeholders. Ambiguity breeds discontent; and even well-meaning stakeholders are likely to develop opinions contrary to the intent of the project.

First line of defense against scope creep

In addition to defining what the project is intended to deliver, the project charter also provides clarity to the scope boundaries of the project – what it is NOT intended to deliver. This is helpful as future scope interpretations are made and change requests are evaluated.

Cross-functional relationships

Many projects require the involvement of multiple teams or functions – each potentially having their own priorities and directions from management. The project charter articulates a “common goal” to which the entire project team can align.

Directing project resources

Project managers must often direct resources from other parts of the organization. This includes financial, intellectual property, technology and human resources. The project charter provides the project manager with the authority to direct and consume resources on behalf of the organization.

Establishing success criteria

The project charter begins the process of describing success for the project. Defining the finish line for project activities and the desired outcomes is essential to ensure projects are executed both effectively and efficiently.

Project management best practices suggest every project should have a clearly defined charter at the onset and this document be reviewed periodically when either significant changes are considered or at key project milestones. The project charter is the “North Star” project managers, project teams and stakeholders can use to guide their evaluation of the project’s course and whether it is progressing towards the intended project goals.

The triple constraint of project management

No discussion of project-management best practices would be complete without a mention of the triple constraint. The triple constraint is a best-practice construct that depicts the relationship of scope/quality, resources and time within the context of the project. One or more factors, often two, constrain all projects and project success and can only be achieved by balancing these 3 factors. For example, if the project is given a fixed timeline and a limited set of resources, then the only factor that can be adjusted is the scope and quality of what is delivered. If a project receives a scope-change request, then it can only be accommodated with a change to resourcing (adding more people), a change to scope (removing another element) or a change to time (extending the delivery date).

Each project is different, and the triple constraint often weighs heavily on a project manager’s selection of a project management approach. Timelines that highly constrain projects, but with scope flexibility, are often well-suited for Agile methods. Projects with constrained scope/quality are often better suited for waterfall-type project-management approaches.

The triple constraint also impacts decisions about project deliverables. Resource and timeline constraints can lead project teams to de-scope key features, accept defects, forego non-functional requirements and scale back supplementary deliverables, such as product documentation. As one might expect, the project’s risk tolerance and the risk-management approach also influence these kinds of trade-off decisions. Project managers often struggle with explaining the impact of trade-off decisions to project sponsors and other stakeholders. The triple constraint is a tool most stakeholders can intuitively comprehend, so its use has developed as a key project-management best practice.

Critical-path-analysis best practices

Project management is the orchestration of project resources and project activities. One of the key activities of the project-planning process is developing a critical path for the project that outlines the key sequence of activities that must be performed to reach the project’s stated objective. Where the product-breakdown structure depicts the end deliverable, the work-breakdown structure, activity map and critical path depict the activities that must be resourced and completed.

Together, these planning artifacts provide the project team with a clear picture of where they are headed and how they will reach the end point. Critical-path analysis is not just a best practice, it is an essential project-planning activity. A well-articulated critical path will help the project team:

Avoid distractions – The project may have many activities, but not all of them are critical.

Allocate resources efficiently – Critical-path activities often are assigned to the strongest project team members.

Track project progress – The critical path provides a reference point for tracking progress towards project completion.

Deliver confidently – Team members who understand the critical path can clearly see how their efforts contribute to project success.

Critical-path analysis is often performed as a part of a project’s planning stage. It is not uncommon, however, for the critical path to change as the project proceeds. Best practices suggest the critical path be reviewed as a part of reviewing each change request and project milestone to understand if a change to the critical path has occurred and if changes must be made to the project plan.

Best practices for managing project resources

Resource planning is one of the most time-intensive project-management activities. Project managers are responsible for directing financial resources, intellectual-property resources, technology resources as well as the human resources assigned to the project. Much of this is basic scheduling, budgeting and administrative work that is not very complex or difficult. Human-resource management (coordinating people’s activities) is where nuances and challenges often occur. Project-management best practices suggest 5 areas where project managers should pay careful attention when managing project resources.

Estimating overhead activities

Most project managers underestimate the percentage of each team member’s time that overhead activities consume, either directly connected to the project (status reports, project meetings, documentation, etc.) or related to their day job (staff meetings, performance reviews, etc.). During a typical project, overhead activities consume 30–45% of a resource’s time before he or she begins to work on project deliverables.

Managing turnover

During projects lasting more than 3 months, project managers should expect at least some resource turnover due to natural attrition and people changing job roles. Best practices suggest turnover should not be avoided (e.g., contractually locking resources into their role on the project), but rather mitigated through cross-training and maintaining enough schedule reserve to accommodate resource changes.

Understanding skills and capabilities

Many project managers overestimate the skills and capabilities of project team members and underestimate the learning curve for achieving peak project productivity. This can lead to unrealistic expectations and project team members working overtime to achieve project expectations.

Planning for disruption

A big mistake inexperienced project managers make is developing resources plans based on best-case scenarios and failing to plan for an expected level of project disruption. Risk-management processes provide a structure for evaluating both known-unknowns and unknown-unknowns in a project. Unknown-unknowns are where the biggest issues occur.

Managing competing priorities

It is very rare that a project is staffed with a team of people allocated 100% to project activities. More often, resources must balance project activities with other projects and/or operational activities outside the project manager’s control. Understanding competing priorities and capacity limitations will help improve the quality of resources estimation for the project.

Best practices for project-change management

Most projects don’t have the luxury of occurring in a static environment – the organizational needs, business environment, technology landscape and resource profile are constantly changing. One project manager described this as “trying to change a tire on a bus as it is driving on a road.” Although not all changes can be anticipated, project-management best practices suggest there are 4 key factors which can help a project manager anticipate how much their project may change.

Length of the project

Shorter projects tend to be more stable while longer projects have a higher likelihood of significant changes occurring that must be managed.

Stability of the environment

Some business environments are more stable than others. In highly dynamic organizations and industries, the project environment is likely to be more volatile.

Easy-to-use software promotes adoption

People will naturally try and do their jobs in the easiest way possible. Since most project-management activities can be done manually, software must be simple and effective and achieve the specific results the user is seeking.

Versatility of resources

Human, technical and financial resources that are highly versatile can insulate the project from many changes and avoid disruption. Projects staffed with specialists are prone to change related disruption.

Not all project-management methodologies address changes the same way. Agile and rolling-wave methods excel at managing change and, in some cases, are optimized to anticipate and embrace change. Waterfall methodologies and projects with rigorous compliance requirements often struggle to adapt to changes and, in some cases, even a small change can cause significant rework and/or project abandonment.

Project-management best practices suggest the best method to approach changes in a project environment is to apply continuous-improvement approaches. Instead of assuming the project team is all-knowing and every facet of the project plan has been determined in advance, project managers should plan to learn as they proceed by continuously surveying the environment both inside and outside the project for opportunities and threats. When they are identified, the project manager should carefully consider the impact of the change, leveraging risk-management techniques and the triple constraint when formulating a response. Many changes lead to requirements refinement, adjustments to project plans and/or identification of potential defects to the product being developed. By being adaptable and refining the project based on changes, opportunities and threats, project teams will not only be able to achieve the objectives stated at the start of the project but also, more importantly, deliver the outcomes at the end of the project the organization actually needs.

Project management software best practices

Project management, like every other discipline in modern business, is heavily dependent on technology and data to be effective. Unlike other disciplines, however, technology has not had a significant impact on how project-management processes are performed. The same activities that were once done manually software now support to improve efficiency, but the level of the project manager’s effectiveness has not changed significantly.

Some of the most common project-management activities, which software support, include: requirements management, scheduling, tracking status, managing risks, processing change-requests, tracking testing activities and monitoring conformance. A quick scan of this list reveals technology and automation can support both data management and workflow-related activities. Looking at the list even closer, the nature of many of these activities is like those encountered in the IT Service Management (ITSM) space (continuous operations).

This similarity has led many companies to leverage the same capabilities to support both IT project management and IT service operations. The best practices and lessons learned from ITSM can also be applied to project management software.

Scaled to project needs

There is a wide range of sophistication in project management software, from simple spreadsheets to complex project and portfolio management systems. Project management software should be scaled appropriately to the needs of the project.

Beware of unnecessary overhead

Project management software should provide the needed capabilities in the most efficient way possible. The best way to avoid overhead is to focus on how the data you capture is being consumed – if you can’t show how data will be used, then you may not need to collect it. The same applies to workflow activities.

Easy-to-use software promotes adoption

People will naturally try and do their jobs in the easiest way possible. Since most project-management activities can be done manually, software must be simple and effective and achieve the specific results the user is seeking.

One key area where project management software adds significant value to the overall company that may not be obvious to the project team is in brokering the interactions between project teams and operations functions. These aren’t often recognized because they are interfaces between project management and operations and neither one owns them. There are 2 key interfaces on which project management best practices suggest teams focus:

The transition of project to operations

A project, by definition, is a temporary endeavor. When the project ends, all the project-related artifacts, deliverables, knowledge and work-products must be transitioned to the functions in the organization that will support and operate them. While it is common to transfer release notes, source code and open issues lists, these “hand-off artifacts” often lack an explanation of why certain project decisions were made. Project planning, risk management, change control and testing documentation can be valuable resources to help support systems and make future changes in a safe and effective manner.

Feedback/input from operations functions

Project teams delivering multiple releases need an effective method to capture feedback from operations functions, including user feedback, performance statistics, operational defects and stability issues. Most of this information is stored in the company’s ITSM system. Problem-management workflows should be integrated with project-management processes, such as defect management and change management – providing project teams with a view of the insights gained through operations.

Integrating project management and ITSM

Project teams are tasked with delivering changes to the products, services and processes of an organization with the goal of creating some sort of value. That value is often not realized (at least not fully) until after the project has concluded and the outcomes of the project have been embedded in continuous operations. Think of this as an up-front investment for benefits realized during an extended period. This is important because project teams must be keenly aware of the long-term impacts of short-term decisions.

As project teams make decisions about scope, quality, timelines and project costs, they must consider the impacts of those decisions on the active operations of the company. The outputs of every project have an expected, useful lifespan. During that time, costs will be incurred (operations, cost of goods sold, maintenance costs, etc.) and value will be realized (staff productivity, business insights, revenue opportunities, etc.). As project teams forecast the ROI of their projects, they must consider the lifetime impacts.

Best practices suggest project management be viewed as an IT Service Management discipline, directly contributing to the active operations of the company. ITSM methodologies (such as ITIL) depict service management as a continuous cycle of change impacting operations. Project teams are important to enabling both the creation of new services and continuous service improvement.

Project deliverables should be designed and optimized to maximize operational value and minimize operational cost. When defining the minimum viable product (MVP), project teams should consider end-user experience and operational impacts, not just the stated objectives of the project charter. The project team can fulfill every project requirement, but if the product is not usable, the organization will not realize the intended value.

Project teams should be wary of defects found during testing, accepted by the project team and left unresolved at the time of project closure. These accepted defects don’t disappear when the project is delivered – they become support issues that impact operational costs and organizational value. Project delivery (go-live) isn’t the finish line, it is the starting line of a new and enhanced set of capabilities delivered to the organization.

Other Related Resources

implementing lean in itsm 2x implementing lean in itsm 2x

WHITEPAPER

Lean in ITSM
blog img apoorva blog img apoorva

BLOG

How To Effectively Manage Change With Project Management
agile itsm 7470bf1e agile itsm 7470bf1e

BLOG

What is agile in ITSM
service management should follow these product management practices service management should follow these product management practices

BLOG

What can service management learn from product management?