5Ws 1H: A technique to improve Project

Management Efficiencies
Project management can be regarded as a multipurpose techno-managerial activity. The diversity of its
applications necessitates making PM inclusive. One way to do that is to broaden its knowledge circumference
by integrating new tools and techniques with an aim to enhance the quality of PM processes and the quality of
products / services produced using these processes. Yet, in hindsight, it seems that use of quality management
tools and techniques have not captured the deserved attention from people working on the projects. There
could be several reasons; from people lacking knowledge or intent (or both) of how to use quality management
in projects, to a more systematic problem of lack of integration of tools, techniques, standards and general
awareness for people to use quality management techniques regularly and effectively.

With an intention to build further thought and propose some new tools / techniques, one technique that carries
good potential for use in PM for problem solving is called by the name 5Ws 1H (or sometimes 5Ws 2H).

5Ws 1H (or 2H) explained

5Ws stand for What, Why, When, Where, and Who.  1H (or 2H) stands for How (and How much). For a detail
description of origin and history of the concept, see https://en.wikipedia.org/wiki/Five_W

What: Thinking of What initiates the process of understanding the basics of issue, problem or scenario at hand.
It is about cognitive mapping of the scope of the issue, problem, or scenario.

Why: Asking ‘Why’ entails clarifying why the issue, problem or situation at hand occurred. It aims to identify the
triggers and rationalizes the occurrence of an issue or a problem.

When: This element is about time-stamping the occurrence of an issue or a problem. Having an understanding
of the time of occurrence could help in sequencing the triggers and impact of the issue, or problem.

Where: This element is used to pinpoint the location or place of occurrence and hence could be helpful in
identifying the people and other things present / existing at that location which may have contributed to the
occurrence of an issue or problem.

Who: This is about identifying people who may have direct or indirect involvement in causing or contributing to
the issue or problem.

How: This element of technique is used to examine the sequence of things and triggers and how the resultant
problem or issue unfolded.

How much: This indicates the quantity, volume or size.

5Ws 1H (or 2H) explained through a project management-based scenario.

Taking a Software development project as an example, we consider a scenario where development team has
found that technology they are using is not fully compatible with the existing systems of their client, as was
previously thought. So the project team can consider using 5Ws 1H (or 2H) to understand the problem and its
extent of impact.
1. What: The team can ask following questions to build an understanding of the fundamental problem and
scope of the problem

1. What is the technology we are using for software development?

2. What technologies were considered initially for this development project?
3. What was known about the existing system(s) of client?
4. What checks and verifications were done to confirm the compatibility of the technology being built and the
deployment acceptability of new technology on existing client system(s)?
5. What (if any) approved or unapproved modifications / changes have been made following discussions on
technological compatibility since the start of the project?
6. What expertise is available to the team to help them understand the compatibility issue?
7. What are the accepted processes for managing compatibility and technological synergies?
8. What guidelines or standard operating procedures (SOPs) are available to deal with such issues?
9. What actions were taken once the problem was detected?

2. Why: The project team may ask ‘Why’ questions to get a more granular understanding of the problem and
seek to clarify triggers or drivers that may have contributed to the issue. Some of the questions that can be
asked are:

1. Why has it happened that two technologies are now found to be incompatible?
2. Why was this problem not identified earlier or at the start of the project?
3. Why technologies cannot be made compatible?
4. Why were quality assurance processes not able to detect the problem?
5. Why were project team or experts involved in the project not able to detect the problem?

3. When: By using ‘When’ questions, project team members can time stamp the events and understand the
relationships among various events that may have influenced the emergence of incompatibility issue.

1. When was the problem first detected?

2. When was client system(s) information / architecture evaluated?
3. When were compatibility issues mapped and discussed?
4. When were any compatibility tests done and compatibility found acceptable?
5. When was any incompatibility impact assessment done?
6. When was the matter taken up with client or client informed?

4. Where: By asking ‘Where’ questions, project team can get a better handle of source(s) of the problem.
Some questions that can be asked:

1. Where are client system(s) located?

2. Where are development teams located?
3. Where are quality assurance / testers located?
4. Where is documentation on system compatibility kept?
5. Where is any approval / change management documentation on system architecture and compatibility kept?

5. Who: The project team can ask questions to identify the people involved in contributing to the issue. Some
questions that may be asked:

1. Who is responsible for ensuring technological compatibility within the project team?
2. Who is responsible for data gathering and client system(s) mapping on project team side?
3. Who is responsible for design and change management approvals?
4. Who is responsible for providing client system(s) information and technical details to the project team from
client side?
5. Who is responsible for overseeing the compatibility testing and reporting?
6. Who is responsible for problem detection and escalation?
7. Who is responsible for problem firefighting and liaison?
 8. Who detected the problem or came to know the problem first and who were informed first?
9. Who escalated the problem and informed the firefighting parties?

6. How: To understand the sequence of various inter-related events, the project team can ask how questions
such as:

1. How did the problem happen?

2. How has the sequence of events led to detection of problem?
3. How are compatibility issues handled and key activities identified in the project?
4. How are compatibility documentations prepared, shared and stored?
5. How are compatibility tests performed?
6. How is the potential of incompatibilities minimized and a better understanding is gathered about
technological compatibility?
7. How are roles and responsibilities within project delineated and how is accountability ensured?
8. How is disconnect between project teams minimized and proper communication maintained?

7. How much: A later addition to 5Ws 1H technique, this element is used to gauge the size of the impact.
Some questions that can be asked are:

1. How much is the estimated time and cost loss to the project due to emergence of this incompatibility issue?
2. How much estimated time and cost is needed to resolve the issue?
3. How much are the increased risks to the core objectives of the project due to this issue?
4. How much impact will this issue have in inducing long term system vulnerabilities even after compatibility
issues are resolved?
5. How much would the loss be to business from this client or similar clients due to emergence of the issue?

Concluding thoughts:

Integration of new tools and techniques should be an ongoing process to deal with emergence in project
management practices. In particular, problem solving and quality management techniques could help improve
the overall effectiveness of project delivery. 5Ws and 1H (or 2H) technique is simple, logical and has what it
takes to be used with minimum cost to the project. Practicing it on regular basis could help project teams to
become naturally more problem-solution oriented. It is important to note that the list of questions used above is
for illustration purposes only and should not be considered exhaustive or complete.

Acknowledgement
Special thanks to post-write-up contributions by Roger Tagg.