Tag: Project Management

Best of PMTimes: Closing a Project: What, When and How

Written by Bola Adesope on April 5, 2023. Posted in Articles. 5 Comments on Best of PMTimes: Closing a Project: What, When and How

Projects, by nature, are to be closed. I am sure you know this. The two authorities made this obvious in their definitions of what project is.

Take a moment to review the definitions from PMI and AXELOS.

A project is a TEMPORARY endeavor undertaken to create a unique product, service or result. (PMBoK Guide 6th Edition)

The above is the definition of a project by PMI (Project Management Institute), an organization founded in 1969, with headquarters in the USA and who has been providing guides, standards, and certifications, amongst other things, on project management since its inception. The key word is that definition is TEMPORARY, which literally means must have a start and end time.

Let’s move over a minute and take a look at the definition of a project from another body.

A project is a temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case (Managing Successful Projects with PRINCE2, AXELOS)

One thing is common to the two definitions. Did you see it? Yes. It’s the word TEMPORARY. A project is temporary and must be closed. Don’t confuse the term TEMPORARY with SHORT. I have got few of this concern from some of the students I train. A project can be for between 1 month and 36 months. It just means it must start and end at a particular date

Now, let me take you through the WHAT, WHEN AND HOW of closing a Project.

Note: I will not discuss whether the project is successful or failed.

WHAT is Closing A Project?

It’s has been established that every project has a start date and an end date. So, the process of completing the work on the project to an end is exactly what closing a project is. Nothing more, nothing less. If you are not closing an exercise or ending an exercise, then you need to know that the exercise isn’t a project.

It could be an operation. One of the differences between a project and an operation is that while projects are temporary, operations are ongoing and continuous. No matter how long the duration of a project is, it must end.

WHEN do you CLOSE a Project

Well, there are three circumstances under which a project can be closed. Yeah, THREE! One out of every ten readers of this article will find this surprising. Just give me a second and I will explain the three times.

1. When the project has delivered all the objectives and/or RESULT.

This is probably the most popular and most desirous time when a project should be closed. At the beginning of the project, a set of objectives, deliverables, and results were set. The PM and the whole organization rolled up their sleeves and started working towards building and delivering the objectives and deliverables for the project. Once the objective is met and the deliverables completed and accepted by the Project Sponsor/owner, it is time to close the project. Reason? The PM and the team have completed all they committed to, and there isn’t anything left to do on the project. What if there is a modification or an addition to the deliverables of the project. Well, that’s called scope creep, if there is no adjustment to other components that may be affected, and once the addition didn’t go through change control for approval, and no re-baseline, then it has to be initiated as a new project, after closing the current project.

For PRINCE2, Once the project has delivered what was specified in the business case of the project mandate, while for PMI, once it has developed the content of the approved scope.

2. When the objectives of the project can’t be met again

This is often called TERMINATION. Hopefully, it can be done early.

This is usually not a very pleasant one, but it’s usually a reality. It could be as a result of the complexity of the project or a combination of many other things. I recall working on a project with some client in the financial services industry a few years back. The business case and feasibility were highly optimistic and the organization decided to invest in the project hoping for the objective to be realized. However, after series of attempts, efforts, and re-baselining by the project team and the stakeholder, it became clear to even the blind stranger that the approach and the technology chosen for the project couldn’t meet the objective, the organization had to terminate the project for that same reason.

At times it could be that the organization had spent so much money on the project, yet they haven’t realized any benefit and at every point in time, there was no sign that the project would still deliver the objective.
Please note that in most cases, the project manager and the team are not responsible for this, and often should not be blamed.

Advertisement
[widget id=”custom_html-68″]

3. When the objective of the project is no longer needed

This is often called early termination.

We live in a dynamic and constantly changing environment, and there are many actors and factors driving the market and corporate space. Most of these factors could be a technological change, a governmental policy, a change in strategy and direction for the organization etc. PRINCE2 advises that at every point on the project, the project organization should continually check for business justification, to ensure the business case is still valid. If at any point the organization realizes that the business case has become invalid, the only thing left is to close the project. A typical example was a project I was working on for a client to penetrate a new market and release a product that would solve a particular challenge. We were about 45% into the project when the government introduced an initiative that would address a similar challenge at no cost. It became obvious that the product would not make many sales, hence the objective and business case became invalid. We had to terminate the project immediately. This is better than going head to complete the project. Organizations don’t just initiate or complete a project for the mere sake of completing a project, the product of the project must be valid all through and the end product must be desired and desirable at all time.

Another example was a consulting project I was working on with a startup to rebrand the company. Midway into the project, there was a merger and acquisition with another company it became instantly known that there was no need to rebrand the company anymore. Again, this could be at no fault of the project team.

In the next section, I would highlight how to close a project, irrespective of when it is closed.

HOW to close a Project

No matter when. You need to close the project. About three years ago, I worked on a research project with about twelve other professionals to review project management processes and health check of organizations within three continents, and we found out that a lot of organizations don’t close projects well, and this is quite worrisome. As they were completing one project, the team was being drafted to other projects or assignment without proper closure process. Hence the reason I decided to write this article.

This process will be broken that into two different sections. The first section will highlight steps to closing a project whose objectives have been met, while the second would highlight the steps to close a project whose objective is either not needed again, or can’t be met.

How to close a project whose objective has been met.

Confirm that all the deliverables have been completed and accepted by the appropriate approving authority. Here you will need to reference your plan, specifically your approved scope and acceptance criteria
Obtain formal acceptance and approval (this could be by way of formal SIGN-OFF or whatever method has been agreed upon).
Close any procurement component of the project.
Gather the team and update lessons learned on the project.
Release all resources and provide feedback as required.
Complete end of project report and archive project information.
Celebrate. And I mean it.

How to close a project whose objective can’t be met or whose objective is not needed again

Validate the reason for the early termination.
Determine all the deliverables that have been created so far, and ensure they are accepted.
Obtain formal closure notification from the Sponsor.
Close any procurement engagement.
Update lessons learned with the team.
Release resources and complete end of project report, capturing the stage the project was at when it was closed, the reason it was closed and the lessons learned and archive project information.
Celebrate (if you have the courage to).

To Drive Project Excellence, Take Charge of Your L&D Efforts

Written by Gary Scharf on March 29, 2023. Posted in Articles.

In an ideal world, you should be able to draw a straight line from your organization’s Learning and Development (L&D) initiatives to business success. It follows then that, as increased business success depends on excellence in project delivery, more companies should focus on building project management training into their core L&D programs.

Some already do. Sixty-one percent of respondents to Project Management Institute (PMI)’s 2020 Pulse of the Profession® Report say their organizations provide some level of project management training. And more than two-thirds (69 percent) say their senior leadership values project management.

But the world is becoming even more “projectified.” Seventy-nine percent of executives in an Accenture study say that work in the future will be based more on specific projects than on roles. And for some companies, project management has become so central to how they operate that it is now considered a core competency.

For all these reasons, some companies are developing more holistic approaches to project management training where the employee experience is embedded into the core of the program.

One of the finest examples of this is the L&D program at CGI. Among the world’s largest independent IT and business consulting services firms, CGI began offering formalized project management training and certification in-house to drive business performance and enhance client relationships. It has now expanded its training efforts to all employees – not just people with ‘project’ in their title.

“Project success is paramount to our company,” says Melissa Reeder, Director of Consulting and Project Management Center of Excellence at CGI. “Engagements are integral to service delivery, so we emphasize providing high-quality project management training to our consultants.”

An important related goal, Melissa says, is to improve its employee career journey and to create a supportive career-building environment. The CGI initiative empowers their employees to take charge of their career development by providing an all-inclusive project management track tailored to each employee’s career stage and project experience.

CGI now views project management/leadership as a core skillset and an essential element in driving improved client delivery success. This skillset, the firm believes, will only grow in importance as work becomes more hybrid.

But there’s another factor behind the CGI training effort. Several of its US-based clients in the government and healthcare sectors require project leaders to be certified in project management – specifically to hold PMI’s Project Management Professional (PMP)®certification.

Advertisement
[widget id=”custom_html-68″]

As PMI’s Leader for North American Client Engagement, that’s how I became familiar with the CGI program. We began working with the firm to develop its project management training track in 2010.

“PMI best practice guidelines are recognized worldwide, and its certifications align with the many types of services CGI provides our clients,” Melissa says. “CGI’s project delivery frameworks are based on industry best practices, so it makes sense for our people to have the same standards of training and credibility that comes with PMI certification.”

To develop well-rounded project professionals, CGI offers its employees the following:

PMI Project Management Professional (PMP)® Certification: Recognized by CGI clients as the project management certification of choice, the PMP certification distinguishes project managers who have proven they have the skills to manage complex projects successfully. The PMP exam covers the latest business trends across three domains – people, process, and business environment – giving certification holders the tools to determine the best way of working and the ability to manage any project using predictive, agile, or hybrid methodologies.
PMI Agile Certified Practitioner (PMI-ACP)® Certification: The PMI-ACP formally recognizes the practitioner’s knowledge of agile principles and skills with agile techniques. The PMI-ACP spans many approaches to agile such as Scrum, Kanban, Lean, extreme programming (XP), and test-driven development (TDD).
PMI Membership: Through the PMI partnership, CGI members also have access to discounted PMI membership to help build a professional network. Becoming part of a professional practice community creates informal learning opportunities with peers, a ready-made professional support network, and space to share knowledge and expertise.

Since the start of the program, more than a thousand CGI members have successfully been PMP certified. The firm is now looking to expand its partnership by connecting its people in Australia and Canada with local PMI chapters.

“Membership in a professional organization is another way to enhance the employee experience at CGI,” Melissa says. “There are vast opportunities to connect and learn from each other, plus it’s a great chance for CGI employees to enrich the profession with their frontline experiences and knowledge. I’ve been an active member of my local PMI chapter for a few years. It’s a great way to meet new people who share a common passion and to give back by volunteering.”

CGI’s employee-centered approach to project management training shows that employee experience and client satisfaction go hand-in-hand. When you deliver quality project training across your organization, it will inevitably impact client delivery for the better.

“We are always looking at ways to enhance our project delivery and client relationships,” says Melissa. Leaders strive to exceed client expectations and the firm’s project management L&D training track is now an integral part of its client engagement strategy.

Delivering consistently high service standards leads to delivering strong projects and value for clients. By offering project-oriented training programs within an organization, your teams will be equipped with the tools and know-how to do just that.

Potential Challenges With Ongoing Projects

Written by Martin Fenelon on March 28, 2023. Posted in Articles.

When joining a project that has already started or when tasked to review an existing project, a Project Manager is faced with a number of challenges. These primarily relate to not having been with the project team from the beginning and, therefore, not having been part of the planning process. As noted in a prior article, scope, schedule, and budget are probably already set. Many other decisions have also been made, some explicit, some implicit. This leads to the first challenge that the new PM has—what is the true status of the project? We’ll describe how to determine the true status of the project in more detail in a future article, along with providing some useful tools. Before going there, we should look at potential challenges that arise because a change in PM is contemplated or occurring. These challenges or issues will be added to those that already exist in the project and will also need to be addressed as part of the takeover and recovery plan.

There are many reasons for another PM taking over a project, and the project itself may not be in trouble; it may truly be in “Green” status. While that is great and makes things easier for the incoming PM, there are still challenges tied to the change in management that must be dealt with. Let’s review a few of these.

First, the previous PM may no longer be available. They may have left the organization, be out on extended personal leave, been moved to a different project, and not available for a hand-off, etc. This means the incoming PM is unlikely to have access to all the information that the previous PM had, especially around the reasons why certain decisions were made. For example, why was the delivery broken into three increments? Why are there four Scrum Teams instead of three? While interviewing the Business Owner (BO), Sponsor, Customer, and delivery team should provide some insights, if we can’t talk to the previous PM directly, we are unlikely to know why they made the decisions that they did.

Second, at the opposite end of the spectrum, the former PM may still be around, perhaps due to subject matter or technical expertise. Since they are still part of the delivery team, there are likely to be team and political issues with them no longer being in charge. The incoming PM needs to understand the reasons for the change and the decision to keep the former PM on the team. Specific actions will be needed to reduce any team or political fallout from the change and to ensure that the team continues to move forward as a team.

Advertisement
[widget id=”custom_html-68″]

Another challenge can arise if the Sponsor, Business Owner, or Customer change at the same time as the PM. Or if one is assessing a project due to a Business Owner change and a project review is requested. There have been cases where a successful Business Owner and PM that work well together are moved to higher priority programs or projects, especially if the current project is going well. This adds to the existing incoming PM challenge of building a relationship with the new Business Owner and rebuilding the team dynamic. Many Business Owners joining a project want to review prior decisions, change requirements and agreements, and potentially alter the goals of the project, all to mold the project to meet their goals and add their personal stamp onto the project. While this is a natural human reaction, it can be deadly in a project. The incoming PM needs to hold the line and minimize the disruption to the project, often without a full understanding of the rationale behind decisions already made. This is difficult to do, even while promising to look further into issues raised by the Business Owner. Diplomacy and firmness are both needed to avoid unnecessarily impacting the project.

Of course, there can be non-political challenges as well. When Project Managers discuss situations that they have found when assuming leadership of a project, it is striking how different they are from starting a new project. One of the key differences is that the ongoing project may already show evidence of problems, or have challenges. We’ve listed some common project challenges and possible causes in the table below. The challenges identified when a new PM is being asked to take over a project will influence the initial steps in assuming command, and should be discussed with management as part of accepting the new assignment. We’ll cover how to handle this in upcoming articles.

As you can see in the table, many challenges (symptoms) can result from similar causes and be related to multiple issues. It is important to avoid jumping to conclusions or developing action plans before getting to the real causes of the challenges. Future articles will describe the how to get to the root causes and ways to address them. In the meantime, how would you assess the true status of a project that you are joining?

For more information on how to handle this situation, and a guide for taking over an in-flight project, please check out my book on the topic. There’s a New Sheriff in Town: The Project Manager’s Proven Guide to Taking Over Ongoing Projects and Getting the Work Done. https://www.amazon.com/Theres-New-Sheriff-Town-Successfully/dp/B0BMJ4J7GL

Integrating User Stories in Project Planning & Deliverable Development

Written by Mark Romanelli on March 14, 2023. Posted in Articles.

An important part of managing any project is being able to break the project down into its component parts. A good project manager and project team need to know and fully understand what a project is intended to do in order to plan and develop the details of the project deliverables.

Project deliverables, according to the PMBOK Guide, are, “Any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project.” (Project Management Institute, 2021). Simply put, deliverables are what a project creates or produces – the output of a project. Those deliverables can be tangible, such as physical objects like products, or intangible, such as events or processes. They define what a project should make or do. When deliverables are correctly defined, each deliverable should come in two pieces. One piece is the deliverable itself and another piece is the associated success criteria for that deliverable. Success criteria can be broadly explained as the criteria used to measure project success (Castro et al., 2019). Success criteria come in a broad range of formats, with elements and standards able to be applied to different projects as appropriate. If a project deliverable is successfully completed, success criteria spell out in detail what that success should look like.

There are a number of different practices for addressing this part of project planning. From informal discussion and consideration to structured, formal brainstorming sessions. User Stories are one tool that every project manager should have in their toolbox for creating and defining project deliverables.

User Stories

A user story is a short statement in the everyday language or business language of the end user of a project’s output that captures, summarizes, and articulates what a user does or needs to do with that output. It states what the user of the project output wants that project output to be able to do or what they want to be able to do with it. User stories describe the features of a projects output from the point of view of an end user.

User stories have their background in agile practices in software development. In this context, user stories are written to describe the features to be included in a software or technology project. Assembled together, the list of user stories makes up the product backlog, or list of features to be built into and included in the project. Based on order of priority, those features are pulled from the product backlog for inclusion in a sprint cycle.

As agile practices have since expanded well beyond the software and general technology sector and into use in all types of projects, so have user stories. They have since become a useful feature in describing the output and elements of various types of projects.

User stories are written in a standardized format. They clearly define the end user in mind (the who), the feature to be described and included (the what), and how the user will use that feature of the product (the why). The format for user stories is, “As a (user role) , I want a (product feature) , so that I can (benefit / use description) . “

Who

The “Who” element describes the role of the user. It asks and answers the question, “who will use the output and receive value from a particular output feature?”.

What

The “What” element describes the product feature itself. This is the deliverable item of the aforementioned output. In agile teams, this would describe one unit of delivery. It is a single, individual feature of a projects output.

Why

The “Why” clearly describes how the user defined in the “who” part of the story intends to use the feature. What will they do with the feature and how does it bring value to the output of the project?

Examples of user stories include:

As a listener, I need a tuning button, so I can find my favorite radio station.
As a theater visitor, I need a ticket, so I can attend the performance.
As a convention delegate, I need a schedule of events, so I can plan my day at the convention.

Several slight variations on the format exist, but the general point is always the same – identifying the user, describing the output feature, and detailing its use or function. The elements can be broken down and considered in those three parts.

Advertisement
[widget id=”custom_html-68″]

Story Cards – simplified approach

Story cards are the tools used to create, arrange, and organize user stories. Each story card is a user story as a self-contained description of a project feature, with additional accompanying elements included along with it to help further define the details of that feature. User stories are traditionally written on physical, individual cards in order to establish the details of each user story and to facilitate the reprioritization and rearrangement of the stories for inclusion in the project. In contemporary practice, story cards can be created and arranged in digital form, using various project management, storyboarding, or digital whiteboard software and applications. Any format works, as long as it can be viewed, shared, discussed, and changed by the project team members.

Just as user stories themselves have some slight variations in structure depending on the specific methodology followed, so do story cards. At a basic level, a user story card should include a title, a value statement, basic requirements, size estimation, and acceptance criteria.

Title

The title of the story card is exactly what it sounds like. It is a shortened or abbreviated name of the story. It should be sufficiently expressive to describe the feature it defines. Titles help to organize the stories for arrangement and prioritization.

Value Statement

The value statement is the heart of the story card, presenting the user story itself in the format previously set out. It describes the user role, the feature to be included, and the benefit or use of that feature to the end user.

Basic Requirements

The basic requirements section is a flexible element of the story card and can be used to further define some of the essentials or expectations of the feature or its development. This can include anything from aspects of functionality to resources or constraints in producing the feature. The Basic Requirements element can be included or omitted at the discretion of the project manager or as the feature itself necessitates.

Size Estimation

In agile methodologies, the size estimation is typically done using an estimation point system. In other practical usage, a time estimation is useful to include and sufficient to further define the story. This is done by estimating, in time or work units, how long the feature will take to complete as described.

Acceptance Criteria

Acceptance criteria describe the basic benchmark that has to be met in order to consider the story complete. It is a description of a successfully completed and functional feature. Acceptance criteria can be written by asking and answering the question, “If this feature is successfully included, what does that success look like?”

Application

In agile methodologies such as Scrum, the collection of story cards makes up the Product Backlog, or list of features to be selected for inclusion and built into the project during an iterative sprint cycle. For more traditional methodologies, user stories and story cards can serve a number of roles. They can help to describe and define features of a projects output from an important point of view – that of the end user. In project brainstorming sessions, this approach helps project team members to take on that role in considering features. Once those features are defined, they can be added to the deliverables list for the project, either as final deliverables or for inclusion in an iterative development cycle. Finally, they can be used to supplement a traditional Work Breakdown Structure. In this way, the story cards can create additional WBS tasks and activities for inclusion in the project schedule.

Any way they are applied, user stories and story cards are a useful tool for project managers to have in project planning and development. They provide a structured way to consider project features, activities, and stakeholder groups.

References

Castro, M., Bahli, B., Farias Filho, J., & Barcaui, A. (2019). A Contemporary Vision of Project Success Criteria. Brazilian Journal of Operations and Production Management, 16(1), 66-77. doi:10.14488/BJOPM.2019.v16.n1.a6

Kissflow Project. (2021, November 23). How to Identify and Manage Project Stakeholders? Kissflow Project. Retrieved May 31, 2022, from https://kissflow.com/project/project-stakeholder-management/

Project Management Institute. (2021, March 21). PMBOK Guide, 7th Edition.

San Cristóbal, J. F. (2018). An analysis of the mainproject organizational structures: Advantages, disadvantages, and factors affecting their selection. Procedia Computer Science, 138, 791-798.

Projects are Fragile… Yet Their Failure Is Not Always Indisputable

Written by Karim Houry on March 7, 2023. Posted in Articles.

The flight from New York to London was without incident. The pilot avoided turbulence by requesting timely altitude changes, the flight attendants were attentive, and food and drinks were surprisingly pleasant. The landing, however, was a little rough and those last few seconds surely influenced some passengers’ opinion of this 7 ½ – hour flight. For some, it turned the entire flight into a bad experience or a “failure”… even though – and unbeknownst to the passengers – a rough landing was required for safety purposes given the strong crosswind upon arrival (the landing gear must make contact with the runway as soon as possible). For others, the flight was satisfactory after all.

There are many variables at play that will influence the outcome of a flight and stakeholders (here the passengers) will have their views on the quality of that outcome. The same can be said about projects, what drives them and their final output. What appears to be a failed or semi-failed project might actually contain some silver lining elements.

Projects are fragile

As shown in Table 1, many project risk variables (we count 23 of them) can impact the outcome of a project.

Those can be classified in 5 broad categories:

People
Tools
Communication
Planning
Strategy

Since projects are driven by people, it is not surprising then that the People category is the largest with 9 out of 23 potential root causes of project failure with some occurring at the start of a project but most of them taking place mid-course of a project life cycle which makes it harder to mitigate them in a timely fashion.

A large number of mitigating factors will require pausing the project, otherwise this would be equated to the overused expression of “attempting to change a tire on a moving car’. Many of the proposed mitigants require the intervention of a third party (e.g. stakeholders, steering committee or management). This adds yet another set of challenges to the needed intervention.

Advertisement
[widget id=”custom_html-68″]

Another layer of complexity is introduced whenever project risk drivers are correlated or become part of a domino effect. Did the lack of resources cause the project to be delayed and then the cost overrun? Did the lack of sponsorship lead to the project manager becoming disengaged and project risks not flagged in a timely manner? Or did those variables manifest themselves independently?

In most cases these project risk elements will be correlated that is why it becomes critical to identify them as soon as possible in order to make the appropriate course correction to avoid a project failure.

Table 1 presents a list of project failure causes – from start to end of project – and proposes ways to mitigate them. The purpose of Table 1 is not to simply present a comprehensive list of mitigants (as variations of such mitigants can be implemented as well) but rather to suggest that what is critical is to identify the project risk variable and begin the process of curing it by a variety of approaches.

Table 1 – Project Failure Drivers

Project failure is not always what it appears to be

In light of such a long list of potential project failure points, it is natural to then take a closer look at project failure itself, or more precisely the various types of project failure that might ensue. These can be broadly classified by the nature of the impact to the project delivery, which can have objective characteristics (e.g. defective delivery or cost overrun) or more subjective ones (e.g. poorly communicated outcome even for a successful project).

As shown in Table 2, many apparent project failures can have their silver lining, especially when it comes to impact on ROI (Return on Investment). Indeed, what sometimes appears to be a categorical project failure, can actually hide some degree of silver lining.

Table 2 – Project Failure Types

Finally, it is worth noting, as depicted in Table 2, that even though a lessons learned exercise is a must at the conclusion of every project – especially those deemed to have “objectively” failed – the depth and intensity of such an exercise may vary by failure type as one considers other priorities calling upon an organization’s resources.