Skip to main content

Tag: Skills

Taking Project Document Management Beyond Paper Pushing

Written by Neil Stolovitsky on . Posted in Articles. 3 Comments on Taking Project Document Management Beyond Paper Pushing

Managing a project can require up to 50 different types of documents for planning, tracking and reporting.  Feasibility studies, resource spreadsheets, financial and project plans, supplier contracts, post-implementation reviews, change request forms and project status reports are essential ingredients in successful project management. They are the components of “project documents,” which are the definitive record of a project that details the project cycle from inception to conclusion.

Most project managers would agree that the project document plays a central role in strategically developing the best possible plan, communicating progress and status to all stakeholders. The type of project documents you produce, their formatting and organization are a big part of what makes your organization able to move through the project lifecycle, which consists of:

  1. Definition or Conception – Defining the charter and the details surrounding the project’s objectives are key drivers in building the project’s road to success. The charter document is the heart of project initiation.
  2. Planning – Detailing the project’s overall scope, resource scheduling, client agreements and risk management details.
  3. Execution – Tracking, acting and reacting. Here the project documents are delivering the actuals and updates to the project plan. Cost, time, physical progress and emerging issues are documented in this phase.
  4. Closure – Closure documents detail outstanding issues and/or deliverables, project outcome reviews and best practices for future use.

Documents have a role in each of these phases, helping to keep the project cycle moving fluidly. At the same time, however, documents need managing themselves or they take over the process they’re supposed to facilitate. As they shepherd projects through these phases, managers can easily fall into the trap of producing piles of documents that cloud their vision with redundant information and contribute to a project’s failure. Using a project document incorrectly can minimize a project managers’ strategic value. Poorly managed documents can conceal a project’s true status, create confusion and frustrate those who want answers and those who need to deliver. Sound project document management determines whether information flows effectively through project teams and stakeholders or turns into bottlenecks that cause projects to exceed their time line, budget or scope.

The sheer volume of information contained in project documents and the need to share it among all stakeholders are the primary reasons that project documents can turn into useless paperwork. Although collecting project information is essential, many project managers have trouble focusing on the most relevant information contained in project documents and using it to unclog bottlenecks and update stakeholders. Poorly managed project documents produce the following symptoms:

  • Lack of visibility –Managers and stakeholders have an unclear picture of project statuses and related work. Project documents do not exchange information, creating redundancies that cloud the picture.
  • Weak security – Poor security measures, inadequate business rules and workflows often direct critical project information to the wrong people and impede progress toward goals. 
  • Loss of data – Many project management organizations do not store their project documentation in a single repository. The information in these documents can be lost or so difficult to access it might as well be lost. Lack of data integrity means inaccurate information could end up in decision-making reports.
  • Limited collaboration – Project documents (e.g. spreadsheets) are often managed as unstructured data sitting in emails, on desktops and in paper format. More often than not, project documents are not easily shared among project stakeholders that may need to access information from multiple locations.

Identifying the document management issues specific to your organization is an important first step in eliminating this document management mayhem. The next step is to adopt a best practices approach developed by outstanding project managers. The basic quality that sets great project managers apart from good project managers is the ability to minimize time spent producing documents and maximizing their more important strategic role of managing people. Re-using documents and applying document management methods commonly used in other areas of business are the strategies common to most great project managers.

Re-using project plans, complex business case documents, standard contracts, specification sheets and project status reports helps managers focus on managing the project without getting bogged down in paperwork. Great project managers are excellent at “templatizing” their project documents to make creating them fast and accurate. Eliminating redundant document re-creation by building templates reduces opportunities for errors from repetitive processes such as transcribing, cutting and pasting information.

Document management technology and methods have been evolving steadily almost since documents were first committed to electronic form in the mainframe era. Document management encompasses procedures such as information storage and archiving, integrity and portability – the very qualities essential to productive project management. Here are some of the best practice elements found in the document management world that can be applied to project management practitioners:

  • Document capture – all electronic and paper documents should be in a central repository for easy retrieval.
  • Version control – check-in and check-out options and tiered security, such as read and write access, ensures data integrity.
  • Workflows – the ability to design and apply configurable workflows that map to the business processes.
  • Reporting and analysis – the ability to exchange information between documents for reporting and analysis purposes to provide better visibility across the organization.
  • Collaboration – the ability to share documents among relevant stakeholders, as well as restrict the documents to those who should not have access.

In an ideal world, project managers would be able to capture the finest of details in their project documents and have the ability to retrieve relevant information on demand when they need to make well-informed decisions. That ideal world of agile, informative documents isn’t fictional. It already exists in the corporate world; it has just existed outside the traditional scope of project management. Adapting the sound document management processes that have made legal, financial, compliance and production more efficient will make project management a strategic advantage for innovative companies in any industry.

Don’t forget to leave your comments below.

Neil Stolovitsky has 10 years of IT experience with end-user, consulting, and vendor organizations, along with extensive expertise in business development, software selection, and channel strategies. Neil is a senior solution specialist with Genius Inside.

So What?

Written by Kiron Bondale on . Posted in Articles. 7 Comments on So What?

As we know, 80-90% of a project manager’s time is spent communicating.  The challenge for some project managers is that their communication appears to fall on deaf ears.  Team members don’t follow established procedures for status reporting or issue notification and senior stakeholders procrastinate or avoid decision making, issue resolution or risk response execution.

When asked, the project manager might point to minutes from meetings, project status reports and e-mail messages to prove that the requests were made.  Sadly, this ignores a core principle of the basic communication model as per the PMBOK Guide, 4th edition: “the sender is responsible for making the information clear and complete so that the receiver can receive it correctly, and for confirming that it is properly understood”.

If the message encoding the information the project manager is hoping will generate action is not perceived by the receiver to be as important or urgent as the project manager feels, the outcome will not be the expected one.

The project manager may wish to have team members follow certain “common sense” steps for sharing information or for escalating appropriately but if the impact of their not doing so is not clear to them, the team members are likely to perceive this as bureaucracy or micro-management. 

If the project manager takes the time to explain the linkage between the requested information and gaining greater predictability on achieving the project’s objectives and is successful in  communicating how the success of the project aligns with the success of the team members, they are likely to at least understand what’s in it for them and why it is important to the project.  This does not guarantee 100% compliance, but at least expectations were appropriately set.

With senior stakeholders such as a project sponsor, a different challenge presents itself.  If the project manager cannot clearly articulate the business impacts of a decision, issue resolution or risk response, at best, the senior stakeholder will procrastinate, but worse, this poor communication will impact the stakeholder’s perception of the professionalism and effectiveness of the project manager. 

While observing the body language or verbal reactions of senior managers to a project manager who is clearly missing the mark with their communication attempts, I’ve often mentally drawn cartoon bubbles over the senior stakeholders’ heads with the thought “Why are they wasting my time?”.

Even if the project manager clearly explains the business impacts of not fulfilling a request, it may still not be perceived as a high enough priority.  Sometimes, there is nothing more that the project manager can do in this case beyond further escalation but if there is the potential of a downstream impact to other more critical business outcomes, it is the responsibility of the project manager to help the senior stakeholder understand these ripple effects.

It would be wonderful if Star Trek’s Universal Translator existed, but until it does, project managers who are unable to answer the “So What?” question might suffer the same fate as an average red shirted crew member!   

Don’t forget to leave your comments below.

To Escalate or Not to Escalate? That is the Question!

Written by Kiron Bondale on . Posted in Articles. 2 Comments on To Escalate or Not to Escalate? That is the Question!

A review of troubled projects reveals that the inability of the project manager or team to appropriately escalate decisions or issues is a common contributor to failure.

In some instances, the challenge is insufficient escalation.  This either results from the “superhero complex” that some project managers or teams develop (e.g. I can fix the world’s problems by myself) or a lack of appropriate judgment (e.g. I can see the light approaching at the end of the tunnel, but I’m sure it’s just the exit and NOT the train).

In other cases, excessive escalation can cause stakeholders and sponsors to get numb – this is the classic “Cry Wolf” effect.  When a concern emerges that truly requires attention, no one pays attention.

Like many of the soft skills necessary to be a successful project manager, there’s no silver bullet that will guarantee effective escalation but here are some tips that might help:

1. As part of your stakeholder analysis, find out what their escalation requirements are.  Similar to risk bias, stakeholders are likely to have differing views on what kinds of decisions or issues need to be escalated to them for resolution and while you may not be able to tailor your approach to exactly meet these expectations for individual stakeholders this up front requirements gathering can reduce the likelihood of your being far off the mark.

2. Document escalation criteria and processes within your project’s communication management plan.  Such criteria should be objective or at least be supported by examples of the types of events that merit escalation.

3. Leverage an external observer who can provide you with unbiased feedback on a situation.  Obviously you should not abuse this resource with each and every decision or issue that emerges on your projects unless a formal mentor-mentee agreement exists, but having the support of an external advisor can reduce the likelihood that your own intuition is invalid.

4. Make sure you’ve done some analysis.  For example, when faced with a decision or issue you can ask your team to perform a quick expected impact calculation (combining maximum impact and probability of occurrence) based on the question “What’s the worst that could happen if we choose to deal with this without escalating?”.

5. “Once is happenstance, twice is coincidence, three times is enemy action”.  If repeated attempts to resolve an issue or make a decision within the team have failed, escalation can at least reduce the likelihood of further project impacts.

Communication is the most important project management knowledge area, and the ability to effectively escalate is a critical competency for any project manager.

Don’t forget to leave your comments below!

Root Cause Analysis and Corrective Action for Project Managers

Written by Gareth Byatt on . Posted in Articles. 3 Comments on Root Cause Analysis and Corrective Action for Project Managers

Project managers have the immense task of juggling requirements and resources that are often not under their direct control in order to produce the required project deliverables within the limited constraints to which they must adhere (scope, time, quality, etc.). Even if the perfect project plan could be designed and executed, it would not remove all of the risks that could ultimately impact a project. Plans must inevitably change for one reason or another.

During the phases of a project, it could be said that there are three major activities focused on reducing project risk. The first risk reduction activity occurs during project planning, when a proactive risk assessment is conducted and the identified risks are either mitigated or avoided (e.g., by modifying the project plan), transferred (such as through insurance) or accepted (by doing nothing and accepting that “if it happens, it happens”). The second activity is the continual assessment of risk throughout the project. The final risk reduction activity is to hold a retrospective “lessons learned” at the end of the project, which will have the least impact on the current project but will serve to benefit others in the future.

However, for the unforeseen problems that occur throughout a project, risk management is too late, since it has already been completed, and lessons learned are too early, since that is conducted at the conclusion of the project. Corrective action is then a critical process for dealing with ad-hoc problems encountered during projects.

Unfortunately, actions taken to resolve an issue often only address the problem itself, not its underlying causes. Symptoms of the problem are addressed and project resources are adjusted to compensate for the problem, but true corrective action may not be taken. In other words, the causes of the problem remain unknown, meaning the problem may reoccur later in the project and/or in future projects.

Consider this example:

Problem: A design project to develop a new vehicle has come to a complete stop because one of the key work packages for it is on the critical path but is behind schedule.

Action taken: The work package behind schedule is deemed to be a low risk, so it is decided that it will proceed in parallel with other modules, changing the critical path. This means that if no major problems found are with the module, there will be no additional delay.

Note that while the action taken in this example may allow the project to proceed along a modified critical path, nothing was done to identify why the work package was behind schedule in the first place. That is, while the problem was resolved (corrected), no action was taken to ensure that the same problem would not occur in the future (corrective action). In our example, was the module behind due to inadequate capacity of the assigned resources, or for some other reason?

Corrective action consists of two major phases:

  • Diagnosis: Performing an investigation to find the root causes of the problem
  • Solution: Taking action to prevent the causes from recurring

To provide a more detailed breakdown of these steps, we put forward an example “10-step problem solving model” that we hope will be of use in guiding you through a corrective action process. Steps 1 through 5 are for problem diagnosis, and 6 through 10 for solution implementation.

  1. Define the Problem: What occurred, where and when was it identified, when did it begin, and how significant is it?
  2. Understand the Process: What were the process steps that should have been carried out before the problem was found?
  3. Identify Possible Causes: If they did not occur as planned, which of the process steps could have caused the problem?
  4. Collect Data: What information could indicate which of the possible causes actually occurred in a way that would create the problem?
  5. Analyze Data: What does the data indicate about which of the possible causes did or did not contribute?
  6. Identify Possible Solutions: What changes to the processes of project planning and execution might keep those processes from failing in the future?
  7. Select Solutions: Which of the possible solutions identified are the most viable?
  8. Implement Solutions: Plan and carry out the selected solutions.
  9. Evaluate the Effects: Were the solutions implemented and have they worked?
  10. Institutionalize the Change: Update project management guidelines and tools to ensure that future projects are carried out in alignment with the improved processes.

Note that steps 1 through 5 are typically done iteratively, until the causes found are at a depth sufficient to prevent recurrence. For example, if on a software project testing, delays are due to inadequate capacity of the testing software, the reason for the capacity problem would need to be determined in order to prevent such a failure in the future. 

Of course, it is not necessary to carry out this level of investigation and action for every problem that occurs during a project, so an important component of the corrective action process is risk assessment and agreement on a sensible course of action. That is, for each problem that occurs, the relative magnitude and likelihood as part of a risk assessment should be considered before assuming root cause analysis is required.

There are many barriers that prevent corrective action from being carried out effectively. We have already alluded to … a lack of guidance … a process … for carrying it out. That’s the purpose of steps 1 through 10. Other barriers and resulting imperatives for project managers include:

  • There is often a tendency for a single individual to try to perform the investigation and solve the problem without help. However, project failures are often the result of incremental variations within multiple processes, and a single individual is unlikely to be sufficiently familiar with all processes to be able to evaluate them effectively and without bias. Therefore, project managers must ensure that they involve multiple players in the diagnosis of complex problems. They need to encourage their team to “put their hand up for help”.
  • In the rush to solve problems, people make assumptions and jump to causes or solutions without having data to back them up. This leads to tampering with processes, which can result in further problems. Project managers need to be certain that adequate information is available before deciding which actions to take.
  • Corrective action often has a negative connotation in organizations, which means people don’t look forward to being involved. However, many studies have shown that humans and organizations learn more from their failures than from their successes, so corrective action needs to be viewed as simply the process of learning more about how processes actually operate. Project managers need to employ positivity when assessing the need for corrective action and putting the case forward to do it.
  • Corrective action is seen as something that is in addition to the “regular work”, rather than as part of effective business management, as indicated by the Plan-Do-Check-Act cycle.  Project managers who emphasize the PDCA cycle as part of day-to-day thinking, as well as during major milestone reviews, will help others see the more complete picture of their roles. It is certainly an embedded part of Quality Management.
  • Many organizations want to automatically assign the cause of all problems to human error.  The problem with this is that it is insufficient to provide identification of solutions, since the cause for that human error would need to be known. Many of the causes of human error turn out to be deficiencies in information, equipment, and management processes. Project managers who focus on process deficiencies rather than blaming people will find that others are more willing to dig down to the real causes of problems.

There are also challenges specific to project management which serve to make the activity of corrective action more difficult. These include:

  • Many projects involve multiple organizations, each a separate legal entity having unique knowledge/skills for which they are being contracted. This means players may try to protect their own turf (think of the BP disaster in the Gulf, and how the various contractors blamed each other), making the truth hard to find.
  • Project personnel may only consider the current project, rather than future projects, as potential beneficiaries of corrective action. The reality is that all players should be able to learn from investigations and often carry that knowledge into future projects.
  • Similarly, due to the fact that each project has an end-point, it may be difficult to do a full-on evaluation of effectiveness. The value of solutions may only be appreciated in the course of future projects.

Another significant advantage of developing better root cause analysis skills within the project team is that such thinking is fundamental for risk management, quality management and the creation of a “learning culture.”

Don’t forget to leave your comments below.

Duke Okes is an expert in Quality Management with 35 years of experience as a quality engineer, consultant and trainer.  He has worked with dozens of companies in ten countries, and hundreds of organizations have attended his public workshops on auditing, quality systems, performance metrics and root cause analysis.  He is an ASQ Fellow and certified by ASQ as a quality manager, engineer and auditor.  He holds degrees in technology, business and education, and is a frequent conference speaker on quality management.  He is the author of “Root Cause Analysis: The Core of Problem Solving and Corrective Action,” and has published dozens of articles on quality.

Gareth Byatt has 15+ years of experience in project, program and PMO management in IT and construction for Lend Lease. Gareth has worked in several countries and lives in Sydney, Australia. He can be contacted through LinkedIn. Gareth holds numerous degrees, certifications, and credentials in program and project management as follows: an MBA from one of the world’s leading education establishments, a 1st-class undergraduate management degree, and the PMP®, PgMP®, PMI-RMP®, PMI-SP® & PRINCE2 professional certifications. Gareth is currently a Director of the PMI Sydney Chapter, he is the APAC Region Director for the PMI’s PMO Community of Practice and he chairs several peer networking groups. He has presented on PMOs, portfolio and program and project management at international conferences in the UK, Australia, & Asia including PMI APAC in 2010.

Gary Hamilton has 16+ years of project and program management experience in IT, finance, and human resources and volunteers as the VP of Professional Development for the PMI East Tennessee chapter. Gary is a 2009 & 2010 Presidents’ Volunteer Award recipient for his charitable work with local fire services and professional groups. He has won several internal awards for results achieved from projects and programs he managed as well as being named one of the Business Journal’s Top 40 Professionals in 2007. Gary was the first person globally to obtain the five credentials PgMP®, PMP®, PMI-RMP®, PMI-SP® , CAPM® . In addition to these, Gary holds numerous other degrees and certifications in IT, management, and project management and they include: an advanced MBA degree in finance, Project+, PRINCE2, MSP, ITIL-F, MCTS (Sharepoint), MCITP (Project), and Six Sigma GB professional certifications.

Jeff Hodgkinson is a 32 year veteran of Intel Corporation, where he continues on a progressive career as a program/project manager. Jeff is an IT@Intel Expert and blogs on Intel’s Community for IT Professionals for Program/Project Management subjects and interests. He is also the Intel IT PMO PMI Credential Mentor supporting colleagues in pursuit of a new credential. Jeff received the 2010 PMI (Project Management Institute) Distinguished Contribution Award for his support of the Project Management profession from the Project Management Institute. Jeff was the 2nd place finalist for the 2011 Kerzner Award and was also the 2nd place finalist for the 2009 Kerzner International Project Manager of the Year Award TM. He lives in Mesa, Arizona, USA and is a member of Phoenix PMI Chapter. Because of his contributions to helping people achieve their goals, he is the third (3rd) most recommended person on LinkedIn with 570+ recommendations, and is ranked 55th most networked LinkedIn person. He gladly accepts all connection invite requests from PM practitioners at: www.linkedin.com/in/jeffhodgkinson. Jeff holds numerous certifications and credentials in program and project management, which are as follows: CAPM®, CCS, CDT, CPC™, CIPM™, CPPM–Level 10, CDRP, CSM™, CSQE, GPM™, IPMA-B®, ITIL-F, MPM™, PME™, PMOC, PMP®, PgMP®, PMI-RMP®, PMI-SP®, PMW, and SSGB. Jeff is an expert at program and project management principles and best practices. He enjoys sharing his experiences with audiences around the globe as a keynote speaker at various PM events.

How Should We Set Project Goals?

Written by Lisa Anderson on . Posted in Articles. 6 Comments on How Should We Set Project Goals?

FeatureNov2ndAs the headlines on the Wall Street Journal and business magazines are increasingly concerned about the economy in today’s new normal, businesses are re-thinking their business plans and searching for opportunities to increase profitability and cash flow. In my experience, the ones who will be thriving not only in a typical business environment but also in today’s new normal are the ones that put together plans, translate those plans into business, department, individual and project goals, and then execute effectively. Goal-setting is a vital component of this process. 

So, how should we set goals?  There are several keys to effective goal setting:  1) Tie the goals to the business strategy and plan.  2) The goal must be a stretch yet achievable.  3) The goal must be measurable.

  1. Tie the goals to the business strategy and plan – This sounds obvious; however, in my experience, the two do not necessarily seem to relate, or it is unclear how they relate. Each team, department, individual and project team needs to understand how their goals fit in with the big picture – and their value to the business and their team.

There are very few employees who do not care to contribute to the success of the organization. Most would love to understand how their piece of the pie contributes to bottom line results, and it can provide an incredible source of motivation – vastly better than the approach of “do it or be fired” type messages.

For example, when I worked with a company who had to dramatically reduce costs in order to compensate for the increases in oil and gas prices in order to meet their investment bankers’ objectives (and therefore provide value to their customers who were the real motivation of the employees, since many of their customers were people similar to their grandparents or the ‘little old lady next door’), the key to the successful approach was having understandable goals. The employees were not onboard with seemingly investor-specific goals until the leaders tied the goals to the business strategy and customer needs, explained the whys behind the goals, and aligned the goals with the efforts of the project teams.  Then, suddenly, it was in the best interest of the project team to achieve the goals.

  1. The goal must be a stretch yet achievable – In my experience, I’ve seen many examples of obviously unachievable goals communicated. Unfortunately, as soon as the project team, department or employee receives an unachievable goal, motivation is lost.  Often, even worse, it is replaced by fear, which can be quite distracting to making progress towards the goal. For example, when a project team is concerned about negative consequences, they often redirect focus from achieving the goal to how to avoid possible negative consequences. 

Although preferred to a completely unrealistic goal, a relatively easy goal also falls dramatically short of providing an effective tool in driving business results. This can also become common in organizations that have a fear-based culture because the fear of not achieving the goal is overwhelming that it is tempting to sandbag goals. Unfortunately, an easy goal does not provoke brainstorming or teamwork.

On the other hand, when an achievable yet challenging goal is communicated, it can become the ingredient that brings the team together with a common purpose.  And, many times, it results in increased teamwork and motivation.

  1. The goal must be measureable – At the risk of stating the obvious, if the goal is not measurable, how do you know you achieved it? Many times, people struggle and struggle to try to make every goal measurable with numbers. Don’t sweat it – measurable doesn’t have to correlate to numbers. Although numbers are certainly one easy way to measure progress (such as reducing costs by $2 million dollars), not all goals lend themselves to pure numbers. For example, maintaining quality standards while reducing costs is a critical goal. In some respects, it can be measured with numbers (parts per million); however, customer feedback is just fine as well. Take a step back and think about how to measure goals in a way that makes sense for your business.

Setting goals doesn’t cost money; just time, and yet it can result in a significant return on investment for your business, project team or employee. Why not put some thought into how to set project goals?

Don’t forget to leave your comments below.