Skip to main content

Author: Bola Adesope

B.Sc, MCITP, CCNA, MCTS, PMP, ITIL, PRINCE2, BAP, SSYB, SFC, CSSBB, CBAP, MBA.
PMTimes_Apr05_2023

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

Written by Bola Adesope on . 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.

  1. 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
  2. Obtain formal acceptance and approval (this could be by way of formal SIGN-OFF or whatever method has been agreed upon).
  3. Close any procurement component of the project.
  4. Gather the team and update lessons learned on the project.
  5. Release all resources and provide feedback as required.
  6. Complete end of project report and archive project information.
  7. Celebrate. And I mean it.

 

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

  1. Validate the reason for the early termination.
  2. Determine all the deliverables that have been created so far, and ensure they are accepted.
  3. Obtain formal closure notification from the Sponsor.
  4. Close any procurement engagement.
  5. Update lessons learned with the team.
  6. 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.
  7. Celebrate (if you have the courage to).

Closing a Project: What, When and How

Written by Bola Adesope on . Posted in Articles. 74 Comments on 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.

  1. 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
  2. Obtain formal acceptance and approval (this could be by way of formal SIGN-OFF or whatever method has been agreed upon).
  3. Close any procurement component of the project
  4. Gather the team and update lessons learned on the project
  5. Release all resources and provide feedback as required
  6. Complete end of project report and archive project information
  7. Celebrate. And I mean it.

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

  1. Validate the reason for the early termination
  2. Determine all the deliverables that have been created so far, and ensure they are accepted
  3. Obtain formal closure notification from the Sponsor
  4. Close any procurement engagement
  5. Update lessons learned with the team
  6. 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.
  7. Celebrate (if you have the courage to)

Top 5 Myths in Project Management

Written by Bola Adesope on . Posted in Articles. 3 Comments on Top 5 Myths in Project Management

You don’t know what you don’t know”. I have often heard many people ranging from top executives, business managers to the guy at the lowest cadre say different things about project management.

Some of the times, I have been at the center of those discussions. There are two major reasons for these submissions. Either ignorance or wickedness, with huge data supporting the former. To this end, I have compiled, in my opinion, the top 5 Myths in Project Management

Myth no 1: ANYBODY, JUST ANYBODY, CAN MANAGE PROJECTS

There is a disturbing statistic that underscores this myth. You often find managers and top executives arbitrarily assign the role of a Project Manager to just anybody in an organization. The belief is, there is really nothing technical in Project Management. To disprove this myth, let us first look at what Project Management is. According to PMI, arguably the most respected and universally accepted authority is the field, as documented in the PMBoK Guide, Project Management is the application of Skills, knowledge, tools, techniques to project activities to deliver the objective of the project or meet the project requirements. Putting that in perspective, to be able to manage projects, an underlining requirement is that one must possess the skills, knowledge, tools, and techniques for managing projects, and a second requirement is the application of those skills, knowledge, tools, and techniques. Remember a fool with a tool is still a FOOL. If you are not trained in project management, if you do not have the knowledge, skills, if you can’t use the tools and techniques, you have no business managing projects. In fact, the word Project Manager is the most abused lately

Myth #2: A PROJECT MANAGER MUST BE A TECHNICAL PERSON or an SME

Very few topics stir argument every time I facilitate training or Speak at conferences on Project Management. One constant trigger is when I say “A Project Manager is not expected to be a Technical Person”. I understand that it does help a great deal if the Project Manager has some knowledge of the technical space in which the project falls into, but this is not a requirement at all. This is why there are SMEs on projects and the project manager constantly meets with and seeks advice from them. Remember the technique called “Expert Judgement?”
Matter of fact, there is the tendency to become too granular in the technicality of a Project if the Project Manager has detailed technical knowledge of the project. Effective Project Management thrives on communication, documentation and interpersonal skills, and these skills are not the forte of technical people.

Advertisement
[widget id=”custom_html-68″]

Myth ‘#3: DOCUMENTATION IS NOT NECESSARY, OR CAN BE DONE LATER

Unfortunately, this myth comes not only from executives and business managers but also team members. When this category of people fails at the first argument, they tend to shift ground and say Documentation can be done later, but the truth is “LATER NEVER HAPPENS”. Once the final product is approved by the client and signed off, the team is immediately reassigned to another project. The Agile Manifesto, which some have used as the main excuse, never said Documentation is not important. It simply says “working software over comprehensive documentation” and at the end, Agile Manifesto says “while there is value in Comprehensive documentation, we value working software more”. Two points I would like to stress in the manifesto. 1: The manifesto never said documentation, it only says comprehensive documentation and that it very correct. Depending on the nature, size, complexity or the environment of the project, some projects do not require comprehensive documentation but rather minimal documentation. But there must be documentation. 2: The manifesto never said there is no value in comprehensive documentation, it only says there is more value in getting the product out.

Documentation is boring, it is tiring, it is difficult. But just like insurance, it is better to have it and not need it than to need it and not have it.

So, to correct this myth, understand the documentation requirement of the project and give it the required amount

Myth #4: AGILE METHODOLOGY IS THE BEST.

Often, people ask me which is better between agile and the traditional waterfall. My response has always been, both methodologies have their own strength and weakness. The normal practice has historically been that the client explains what he or she wants and magically disappears till deliverable due date simply because he has other commitment and has employed you as a Project Manager to take care of the attention and other details. Yet this same client wants you to adopt Agile. Interaction and Collaboration between the team and the user community (client) are the backbones of Agile Methodology. Understanding the requirement of the project will determine which methodology to adopt. There is no bad or good methodology. Instead, we have an appropriate and inappropriate methodology.

Myth #5: THE HALLO THEORY

Edwin Thorndike defined Hallo Effect as the cognitive in which an observer’s overall impression of a person, company, brand, or product influences the observer’s feelings and thoughts about that entity’s character or properties. While this has been somewhat valuable to Marketing, adopting such in Project Management, where someone who has done very well in their technical field is assigned to be Project Manager, has been constantly discouraged. This is very common in corporate organizations.

These are the Myths I could come up with. Constant education will help address these myths and correct them.

In your opinion, what are the top myths in Project Management

Life Lessons From Daily Stand Ups

Written by Bola Adesope on . Posted in Articles. 5 Comments on Life Lessons From Daily Stand Ups

Everybody on the face of the earth knows about Agile right? No?

Okay, not everybody knows about Agile, but everybody, at some point or the other, has heard about Agile yeah? Nope? Really? Okay, if you haven’t heard of Agile before, let me take a minute or two to introduce Agile to you, starting right from what Agile is, and what it is not.

AGILITY is the ABILITY to balance STABILITY with FLEXIBILITY. For a second, forget the line you just read. Agile is an iterative method of delivering incremental products and values to customers faster. Widely popular within the software development circle, but definitely not limited to software or product development. Agile is being used in lots of other industries and domains aside from IT. It focuses on constantly producing valuable incremental products to customers.

In the early 2000s, a group of 17 thought leaders and practitioners gathered together somewhere in Utah and created what is popularly known as the AGILE MANIFESTO, speaking to what the practice sees more values in, against other concepts.

Agile has so many methods such as Scrum, Kanban, Xtreme Programming, Lean etc. Surely, there are lots of articles and resources online about Agile principles and values. As Agile is not the focus of this article, I will like to take us back to the focus of the article
Scrum, arguably the most popular and widely used method in the Agile Practice has a set of roles, artefacts and ceremonies. One of the ceremonies (events) is called DAILY STAND UP (also known as daily scrum or daily hurdle), a daily meeting of the Scrum team typically time boxed between 5 and 15 minutes, depending on the flexibility and choice of the team. During the stand-up, the team holds the meeting standing up (hence the name Daily Stand Up) and three important and inter-related questions are asked:

  • What did you do (accomplish) yesterday
  • What do you plan to do(accomplish) today
  • What are the impediments in your way

From participating in Daily Stand up, and my understanding of the practice, I have been able to draw three life lessons, which every professional should adopt.

  1. Where you are now: A very popular Management philosophy states that the first step towards progress is an understanding of where one is, and this is by all means similar to the practice in Daily Stand Up. During a Daily Stand Up, the first question and/or report given by every team member is what they have achieved till date (what did you do yesterday). Said in another way, what the current state is. For those involved in Strategy Analysis/Management, the first step in any initiative is to conduct an analysis of the current state. Why is this important? It gives a professional an understanding of the Strength and Weaknesses, and a sense of achievement so far. At every point in one’s life, it is best to access the current state. I often find professionals get too busy that they forget to “take stock”, but I have come to understand the importance of this task from Daily Stand Up to Life as it is
    Interestingly, I have witnessed organizations adopt this same practice. I recall participating in several retreats and strategy sessions at the beginning of the year/quarter/month etc, and during those sessions, the usual practice is to assess the position of the organization and its business units. The Management asks every unit head to give a report of their current achievement and standing. Also, during performance appraisals, every business unit gives a report of what they have achieved so far.
    2. Advertisement
    [widget id=”custom_html-68″]
  2. Where do you want to be: During Daily Stand Up, the second question answered by the team is “What do you plan to do today”. More like “what’s your target? Where do you want to be? What is your future state? In Strategy Analysis, this can be said to be the “Define Future State” stage. It is expected of every professional to set a target as to what they would like to achieve. Without a target, a goal or a future you are working towards, it becomes increasingly difficult to measure achievement or result. Again, this practice from Daily Stand Up should be imbibed by all professionals. At every point, always set a target, create a future state, baseline and re-baseline your future state. Ability to define your future state or your goal and objectives will influence the way a professional leads his/her, this target will shape almost every aspect of ones’ life. Given that, as it is, now imagine a life without a target or a goal. One good tool to validate how authentic your goal or target is, is to use the SMART checklist. (Specific, Measurable, Achievable, Realistic and Time-bound. But since we are talking scrum, I will make the “T” time-boxed) checklist.
    During those retreats and strategy sessions, the management and business units then set a target, an objective or goal that the business will aim to achieve. Every other strategy or initiative of the organization will have to be aligned to the target. Now imagine an organization without a set target or goal.
  3. What are the risks in your way: Things don’t go as smoothly as we plan/want. There are always internal and external factors and forces to contend with along the journey to the future. There are always obstacles, inhibitors towards the attainment of a desired target or goal. Not identifying them, and adequately planning for them is like setting one’s self up for troubles (failure came to mind). This practice, from Daily Stand Up, is also applicable to real life scenarios. The objective of this practice is to identify the forces you need to contend with, along the journey to the future, identify what you would need, and how you would manage them. More like what Project Managers and Business Analysts do in Risk Management.

As professionals, we should make this practice and lessons from Daily Stand Up a way of life towards attaining our goals. We should do this periodically (daily, just like we do in Scrum, weekly, monthly, quarterly and annually). Anyhow, just do it and see you on the part to achieving your desired future state.

The 5Ws of a Project

Written by Bola Adesope on . Posted in Articles. 6 Comments on The 5Ws of a Project

………temporary endeavor undertaken to create a unique product, service or result… (PMBoK 5th Edition)

………..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, 2009 edition)

If you work with projects or in the project management space, you can tell these definitions did not exactly dissect and dimension what project really is. Amongst others courses, I train project management either targeted at preparing individuals to write and take a certification exam or helping participants gain better understanding of the concept and practice of Project Management During those training sessions, I usually get more engagement and assimilation from the participants when I use the concept of 5Ws of a PROJECT to explain “what is a PROJECT”.

To better understand this concept, let’s take a look at a short case study:

ABC Ventures, a retail supermarket dealing in household and grocery products with three retail outlets realized a drop in patronage/sales for three consecutive months, and this had a negative impact on the bottom-line of the organization. To really understand the root-cause of this drop, the company hired a consultant to conduct a study. The consultant deployed an online customer feedback survey targeted at the organization’s customers and prospective customers, with the objective of identifying service delivery gaps, and ultimately eliciting needs and approaches to better service their clients and customers.
The survey received overwhelming responses from current customers and potential customers, and upon analysis, the consultant identified a tight schedule of the customers, and the distance between the customers and the retail stores as the two main bottlenecks, and also identified convenience as a value-driver for the customers. The consultant ultimately recommended an online retail store (e-commerce website) as a way to drive patronage.

Hence, ABC ventures commission the development of an e-commerce site for Q2 2017.

Now, let’s use this case study to explain the 5Ws of a PROJECT

  1. WHY; The very first step in defining a project is to understand the needs/problem or opportunities within the project context. This is more like defining the problem statement. Without a thorough and in-depth understanding of the NEEDs within a business domain, it becomes very difficult to articulate the PROBLEM STATEMENT. This step involves understanding the current state analysis, asking questions such as: How does the business currently operate? What are the issues with the current situation/process, OR what are the things preventing the business from achieving its set target? What are the impacts of the identified issues? The combination of these questions provides a ground for developing and articulating a problem statement. The WHY could also be an opportunity: there is no problem or issue with the current state, but there are opportunities to do more that the organization currently does. Could be in form of a government policy or environmental trend. From our case study above, the WHY is a drop in patronage or sales in all the three retail stores run by ABC Ventures due to the geographically dispersed nature of the customers’ vis-a-vis their tight schedule. Every other thing (the other 4Ws will be built upon this)
    2. Advertisement
    [widget id=”custom_html-68″]
  2. WHAT: Following up immediately from the WHY (or better still, the problem statement) is the question: WHAT can we do to address the above needs? There are usually more than one possible recommendations to address a need. From our case study above, there are possibly two other possible solutions, such as expansion of retail stores to other locations, or a “mobile” store, but upon review of the possible recommendations, the management of ABC Ventures decided on “e-Commerce development”. This is the WHAT of our case study to address the WHY.
    There are a number of methods or techniques used in selecting the best “WHAT” in any context, but a fundamental step involves developing business cases for each of the possible options. A business case will typically include sections such as the need we are trying to address, the available options, the cost implication of each of the options, the benefits of each of the options, the risks involved in each of the options and a “do-nothing” option.
  3. WHO: No necessarily the third in terms of sequence, but after identifying the WHY and the WHAT of a Project, another component of the 5Ws is the WHO of the project. This component speaks to STAKEHOLDERS of ABC Ventures, and it includes the current customers, the potential customers, the management and staff of ABC Ventures and any other stakeholder (individual, group) with an interest in or, anyone who might be affected by the implementation of the e-commerce website, or the finished product itself. The “WHO” is as important as the other Ws. For the project to be successful, ABC Ventures need to understand the profile of the end users and everyone that would interact with the e-commerce website. This involves understanding the geography, the demography and the psychographics of the target end users (the consumers, the operational support etc). The understanding of the WHO will not change the choice of e-commerce, but will greatly influence the way the e-commerce is built (for example, being mobile-compatible if majority of the customers use mobile devices more) or creating a mobile app version of the e-commerce website…etc.
  4. WHEN: According to PMI, for an exercise or initiative to be recognized as a project, it must have a specific start and end time (among other indices). This speaks to WHEN. Not determining when the project is to be delivered will make the exercise open-ended, and hence affect the benefits realization. From our case study, the WHEN is Q2 2017. So, at the end of Q2 2017, all the stakeholders would expect to have an online shop, and the management of ABC Ventures can expect to have some changes in sales, all things being equal. Recall, one of the yardsticks for measuring the success of a project is the timely completion. I believe this is clear in and by itself and requires not much explanation.
  5. WHERE: The last, and most definitely not the least W in our 5Ws of a project is WHERE. Now I must say that some projects might not necessarily have the WHERE component vividly, but somewhere within the project, there is the WHERE component. For our case study, the WHERE could be the location to host the e-commerce website and any other possible consideration for location?

PS: Whilst the arrangement of the last 3Ws is not very important, the first 2Ws must follow the sequence used.

Putting everything together, the below describes our case study using the 5Ws of a PROJECT

Due to drop in patronage as a result of distance and geographic constraints (WHY), ABC Ventures is developing an e-commerce website (WHAT) for her customers (WHO) by Q2 2017 (WHEN) , that will be hosted on a cloud server (WHERE).

I would like to read comments on how you have been able to adopt the 5Ws of a Project on any project you have been involved with.

  • 1
  • 2