Skip to main content

Author: Neil Karan

Solve it with Science

Remember those days in elementary school science class when the teacher would stand up in front of everyone and ask a question that required solving? The question was always designed to get the neurons in our brains firing, and begin brainstorming solutions to the problem. During those brainstorming sessions we’d eventually develop a problem statement or hypothesis, which was synonymously referred to as a hunch amongst the kids in class. Whether we realized it or not, our hunch or problem statement would become the foundation of our problem-solving process; the postulation as to why we felt the subject matter in question was occurring, and the possible causation.   

Eventually we’d start going through the motions of testing our hypothesis; identifying our manipulated and controlled variables in hopes that it would provide us with a responding variable that would confirm our hunch. If at the end of our experiments we found that our theory wasn’t supported, then we’d develop a new hypothesis and start the process again.

So with that said, couldn’t a simplistic view of solving problems the way we used to when we were kids be applied to our problems today? The use of this basic method of theorizing and experimenting can become an intricate tool in solving problems that plague or hinder the success of a project.

This article is designed to remind and re-engage you in a thought process that was taught to us at a young age and that can help you tackle the problems impacting your project today. What this article is not designed to be is an exercise in technical jargon or buzzwords, but one focused more on the utilization of simple logic when trying to figure out the root cause of an issue.

No matter what the issue is, a similar thought process should be running through all our minds when identifying and responding to a problem:

Figure 1

Neil20th1


A. Identify the Issues

Begin by understanding what problems have been plaguing the project (e.g., a lack of project charter, poor team member participation, etc.). A suggested approach is to go through the original plan for the project and perform a gap analysis of where things should be versus where they are today. As a member of the team, or as project manager (“PM”), you should have a good idea of what’s been slowing down the project. Consideration should also be given to collaborative discussions with the team that could also bring to surface issues that may not be apparent to all members or the PM but could have a material impact on the success of the project.

Once you’ve gone through and listed potential problems, the next suggested step is to risk rank each issue to determine their importance and resolution priority.

B. Prioritize the Issues

To determine which issues to tackle first, the suggested approach is to risk rank each issue and prioritize each based on complexity and impact. In this context, complexity can be viewed from many perspectives. But to provide simplicity and ease of thought, consider viewing it from a component standpoint (e.g., how many information inputs and outputs are impacted by the problem, how many parties or business units are impacted, etc.). For example, compare the following three issues:

Complexity:

Neil20th2

Comparing each issue, it’s easy to identify that issue A is more complex than issue C, involves a greater degree of effort to resolve, and impacts more business units and information outputs than issue C. 

Now that we have a basic understanding of complexity, let’s move on to the impact component of the risk ranking exercise.

Impact can be interpreted as the level of damage the issue can cause if it goes unresolved. The damage, for all intents and purposes, is most easily understood when quantified in terms of time required for completion and effort expended; this understanding translates nicely with project timelines and helps provide clarity when the project and identified issues are monetized to the project sponsor. Consider the same issues above, but this time with impact as the risk consideration:

Impact:

Neil20th3

With an understanding of complexity and impact, the final step is to map each against a risk grid. The grid visualizes where your issues rank and helps to vet which issues should be tackled first, from highest to lowest risk. A typical grid that could be used is as follows:

Figure 2

Risk Ranking

Complexity

Low

Medium

High

Impact

Low

Low

Low

Medium

Medium

Low

Medium

High

High

Medium

High

High

Using the grid above, you should now be able to generate a list of issues that are prioritized based on the level of complexity and the overall impact they can have if left unresolved.

C. Figure out the Root Cause of the Problem

Now that you know which issues require immediate attention, the next step is to postulate the cause of the problem, because understanding why the problem is occurring or has occurred will be the only way to develop insight into developing a solution. For example, if the top-ranked risk for your project is that team members no longer attend project meetings, the first step is to develop a hypothesis as to why this may be occurring. The key of the hypothesis is stating the effect and the proposed cause that requires confirmation through experimentation, whether it is confirmed empirically or simply with reasons jotted down on a bar napkin. If, through your hypothesis and experimentation, you determine that no one is attending the meetings (effect) because food isn’t provided to attendees (cause), you can now move towards resolving the issue (i.e., provide food at meetings). The simplicity of the example may seem a bit ridiculous, but you’ll be surprised as to the simple cause of some of the problems impacting your projects.

D. Implement the Solution

The final step when trying to resolve issues is to implement the solution developed during the root cause analysis process. It’s during this time that you’ll be able to tell whether the hypothesized solution will in fact work (i.e., does providing food at meetings actually result in more people attending?). If during this process and the post-implementation of the solution there exists a gap between what is expected versus what actually results, there may be a need to reinitiate the problem-solving process (i.e., repeat step C.)

If the problem is large or complex enough with multiple variables, the above process can become quite extensive but the baseline principles will still hold the same.      

To summarize, thoughtful thinking throughout the problem-solving process is essential to the success of resolving issues in a timely and effective manner. It’s important to be cognizant of your actions and activities throughout a project. Emphasizing a greater effort in planning with a preventative mindset in place aims to ensure that problems won’t arise due to a lack of project charter, multiple project sponsors, etc. If, unfortunately, you are experiencing problems with the project, barring any unusual or extreme circumstances, consider the steps above to help devise a simple and methodical strategy for resolving issues threatening your projects completion.

Don’t forget to leave your comments below.


Neil Karan, CFE, CISA is an experienced financial process and IT auditor who provides direction and guidance for audit and project programs. His areas of expertise include business process effectiveness and efficiency programs, operational process design and financial/IT integrity audits.  


Signs Your Project is Going Off the Rails –Team Member Point of View

At some point in your career you’ve been, or will be, involved in some part or form of a project. Where you find yourself in the project management lifecycle is hard to say, whether it’s in the development of Gantt charts, or right at the end during the delivery and communication of the project; one thing is certain and difficult to deny, whether big or small, something always seems to go wrong. A slightly pessimistic statement to be making and one spoken solely from an experiential point of view as a project member, but historically nothing seems to go unscathed during the project management process. 

Take a moment and imagine yourself as a project member in this scenario:

It’s Monday morning and you’ve come into work. Coffee and notebook in hand you’re looking forward to your kick-off meeting for the new project you’ve been involved with. You sit at the table along with your fellow team members and in walks the Project Manager (“PM”) hired to steer this 12 month project towards the goal line and make it a success. You’re provided with copies of the timelines, project charter, and walked through some pretty fancy slides about the goals and objectives and how this project will be a success. Then you’re let loose with your assigned duties and tasked with having them completed and ready for your next status update meeting. Great, things are looking good and under control. 

Fast forward 8 months, the project is past its mid-point, and you’re now sitting at that same table at the start of the project, except you’ve noticed something’s different. There aren’t as many people from your team sitting around the table; your Gantt chart is now filled with more incomplete stages than complete; the last set of meeting minutes you received were from a meeting held 3 months ago; and your PM is late for the meeting. It’s at this moment you ponder the reality that this project either isn’t going to get done on time, or worse won’t get done at all; panic sets in a bit. So thinking back, you ask yourself “Where exactly is this project sitting? Why does is feel like this project is falling apart?” You think to yourself,  and suddenly all those small things you noticed months ago start flooding back to you: people pushing off meetings; milestones being missed; the PM becoming disengaged with the project; changes in the Project Sponsor, breakdown of communication with the Steering Committee; all signs of a project slowly coming off the rails. 

So, with the typical scenario above why do we bother following project management methodologies that are designed by organizations to help us manage projects (e.g. PMI, OGC, etc) if the project is more likely to fail than succeed. The simple fact is that they provide us discernable stages and a foundation needed to plan and see our projects through to completion. Bottlenecks and roadblocks that usually begin to creep into the project lifecycle and throw it off track, for the most part, come from a poor understanding and enforcement of those principles; which when sifted through leaves primarily the human element of the project at fault, in this case the effectiveness of the PM.

This article, written from the team member’s perspective, will assist you in looking for indicators that will help identify when your project starts veering out of control due to a poor application of project management principles, and when to pump the brakes and get help before the projects ends in disaster.

This discussion will hover over the building blocks for a successful project foundation, not the technical aspects within each project or building block, but rather the general supporting structure.

NKaranPic1

 

Building Block #1:  The Project Sponsor

Significant to any project, is a Project Sponsor. This is the individual with interest and understanding of the project, its direction, and potential benefits. They have something to gain from the success of the project, whether it’s enhanced production, output or cost-cutting measures that impact the bottom line. This is the individual that everyone on the team knows, and understands that their role is to be the primary supporter and champion for the project. 

Red flags should start to go up around the Project Sponsor role, is when:

  • There is confusion as to who the project sponsor is,
  • The role has been assigned to multiple parties,
  • There are conflicting goals and objectives between the PM and Project Sponsor or,
  • The role of the PM and Project Sponsor become one in the same.

If you’re finding yourself asking “Who is the Project Sponsor?” at any point of the project, approach the PM and ask for clarification; if you don’t know, then likely other members of the team are asking themselves the same question. A strong PM will not only have identified the Project Sponsor to the team, but will have worked to ensure that the Sponsor’s understanding and objectives for the project are clearly communicated and understood; the role of the PM is to act as the catalyst for ensuring the achievement of those objectives.

Building Block #2:  The Project Charter

The Project Charter acts as the overarching guideline and vision for the project. This is a document, if done correctly, encompasses, but not limited to, the project background, objectives, benefits, risks, scope, team, approach, significant milestones, reporting structure, etc. Narrative in form, this document tells the story of the whole project, in ideal circumstances, in a well-laid out and structured manner that allows readers to understand from, cradle to grave, the vision and projected outcomes for the project. A strong PM will focus a proper amount of time in creating such a document, as it lays out the fundamental aspects of the project, what is to be done, and the expected results of the effort expended on the project. This document should be provided to all team members, the Project Sponsor and members of the Steering Committee; it should act as the point of reference and baseline for the project. 

As a member of the project team, you should start seeing some eyebrows being raised when:

  • There is no Project Charter, or the PM has no idea how to go about creating one or what should be included within it,
  • A Charter exists, but omits information needed for readers to understand the goals and outcomes of the project or,
  • There is a lack of clarity and/or communication by the PM around milestones, roles, etc.

If you’re finding that there isn’t any substance to what’s provided to you or your team about the project or your role, then the issue should be immediately raised with the PM prior to commencing the project, as a lack of a documented and discernable overview of the project will the prevent the creation of a baseline to which to understand and gauge the progression of the project.  

Building Block #3:  The Steering Committee

The creation of a Steering Committee (“Committee”) is a key factor in the success of seeing a project through to completion with positive results. If developed and comprised of members with sufficient authority, the Committee can provide guidance and resolution to overcoming bottlenecks being faced by the project and project team. A strong PM will work to organize a Committee that meets on a regular basis to discuss the progression of the project, and provide resolution for issues hampering the success of the project. 

As a member of the project team, you should have awareness as to the composition of the Committee, but should raise your concerns to the PM and your team members if the following flags are noted at the inception or through the progression of the project:

  • There is no Committee, or there is a lack of awareness as to who comprises it,
  • A Committee exists, but is made up of members with little or no authority to enforce or support changes resulting from the project,
  • Regular meetings with the Committee are not being conducted by the PM, and there is a disconnect between what is being done versus what is being reported or,
  • There are no meeting minutes or agendas being maintained by the PM to demonstrate that progress and/or issues are being reported to the Committee, and as a result issues are finding no resolution, hampering project progression.

Building Block #4:  Progress Reporting

The tracking of project progress and achievement of milestones is a key success factor not only for the Project Sponsor and Committee members, but also for team member morale; no one enjoys devoting time to something where there are no apparent victories or successes, even a small win can be satisfying to know their efforts are aiding in the success of the project. 

The success of progress reporting isn’t just how far along we push the progress bar on the Gantt chart, but how much progress is being made in relation to the Project Plan/Charter that was created to flesh out the project details. The comparability of the discernable stages in the Gantt chart against the Project Plan helps to identify where wins are being made, where bottlenecks or issues are occurring, and whether the project is progressing through the stages along a critical path for success.

Some questions you should be asking yourself as you look at the Gantt chart provided to you are:

  • Does the chart mirror what was outlined in the Project Plan or Charter?
  • Are we addressing the critical steps needed to successfully complete the project correctly and in a timely manner?
  • Is the PM accurately recording the expected effort versus the actual effort expended?
  • Are we receiving consistent progress updates (e.g. weekly, monthly, etc.)? 

A strong PM will work to ensure that the Gantt chart accurately reflects what was outlined in the Project Charter, as agreed to by the Project Sponsor and Committee, and that communication of progress is consistent and timely. If you’re ever finding yourself asking “How are we doing?” or “When was the last time we received an update?” you may gain benefit in having a conversation with the PM to try and figure out what may be going on. 

Building Block #5:  Communication

The final building block and the one that is pervasive throughout any project is communication; communication to team members, stakeholders, sponsors, and the committees. Effective communication helps ensure collaboration and understanding amongst all parties involved with a project. This is where the PM’s role becomes critical for ensuring conversations are taking place, and people are provided with the information they need to make decisions that drive the project to completion. 

Concerns around communication will make themselves evident in a project quite quickly as a project progresses, or rather its inability to progress, but communication issues to watch for include, but are not limited to:

  • Sporadic meetings with project team members, project sponsor, committee,
  • Contradictory understanding of project objectives and direction amongst stakeholders and team members,
  • Inconsistent reporting of progress to involved parties,
  • A lack of a “communications plan” by the PM,
  • Lack of meeting minutes or agendas,
  • Little to no direction from the PM, Committee, and/or Project Sponsor as to what is a desirable approach for the project; etc.

If you’re noting any of the above items, or realize that your understanding appears to be different from the person sitting next to you, it may be time to question the PM and make sure they understand what is expected of them to ensure the project objectives are communicated in a more effective manner.  

With awareness of the building blocks, if as a team member you’re seeing the project slowly veering off track, how can you make sure your concerns are being acknowledged by the PM? A suggested method would be first to gain consensus amongst your team members and make sure that the misunderstanding is simply not with you, but that other members have the same concerns. If the concerns are warranted and resolution is required, then the team should collectively address the PM with the issues and seek resolution; any unresolved issues will only pose an increasing risk as the project progresses. In the off-chance that you find your concerns falling on deaf ears, escalation may be required. If the team is finding the PM is ignoring legitimate concerns that pose a risk to the project’s success, discussions should be brought forth to the Project Sponsor, outlining concerns along with proposed solutions for resolving the issue(s). Actions that take place after escalation could range from a new PM or simply to a collaborative discussion with all stakeholders to ensure everyone is communicating, but that is left at the discretion of the Project Sponsor. 

Simply put, if as a member of the team you’re noticing issues that you foresee as having an adverse impact on the project, take note and make sure your concerns are known; you may not be the only one wondering what’s going on.

Don’t forget to leave your comments below.


Neil Karan, CISA is an experienced financial process and IT auditor who provides direction and guidance for audit and project programs. His areas of expertise include business process effectiveness and efficiency programs, operational process design, and financial/IT integrity audits.