4.2: 4.3 Dealing with Problems -- Project Management for Instructional Designers
- Page ID
- 39837
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)
\( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)
( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)
\( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)
\( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)
\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)
\( \newcommand{\Span}{\mathrm{span}}\)
\( \newcommand{\id}{\mathrm{id}}\)
\( \newcommand{\Span}{\mathrm{span}}\)
\( \newcommand{\kernel}{\mathrm{null}\,}\)
\( \newcommand{\range}{\mathrm{range}\,}\)
\( \newcommand{\RealPart}{\mathrm{Re}}\)
\( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)
\( \newcommand{\Argument}{\mathrm{Arg}}\)
\( \newcommand{\norm}[1]{\| #1 \|}\)
\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)
\( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)
\( \newcommand{\vectorA}[1]{\vec{#1}} % arrow\)
\( \newcommand{\vectorAt}[1]{\vec{\text{#1}}} % arrow\)
\( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vectorC}[1]{\textbf{#1}} \)
\( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)
\( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)
\( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)
\(\newcommand{\avec}{\mathbf a}\) \(\newcommand{\bvec}{\mathbf b}\) \(\newcommand{\cvec}{\mathbf c}\) \(\newcommand{\dvec}{\mathbf d}\) \(\newcommand{\dtil}{\widetilde{\mathbf d}}\) \(\newcommand{\evec}{\mathbf e}\) \(\newcommand{\fvec}{\mathbf f}\) \(\newcommand{\nvec}{\mathbf n}\) \(\newcommand{\pvec}{\mathbf p}\) \(\newcommand{\qvec}{\mathbf q}\) \(\newcommand{\svec}{\mathbf s}\) \(\newcommand{\tvec}{\mathbf t}\) \(\newcommand{\uvec}{\mathbf u}\) \(\newcommand{\vvec}{\mathbf v}\) \(\newcommand{\wvec}{\mathbf w}\) \(\newcommand{\xvec}{\mathbf x}\) \(\newcommand{\yvec}{\mathbf y}\) \(\newcommand{\zvec}{\mathbf z}\) \(\newcommand{\rvec}{\mathbf r}\) \(\newcommand{\mvec}{\mathbf m}\) \(\newcommand{\zerovec}{\mathbf 0}\) \(\newcommand{\onevec}{\mathbf 1}\) \(\newcommand{\real}{\mathbb R}\) \(\newcommand{\twovec}[2]{\left[\begin{array}{r}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\ctwovec}[2]{\left[\begin{array}{c}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\threevec}[3]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\cthreevec}[3]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\fourvec}[4]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\cfourvec}[4]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\fivevec}[5]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\cfivevec}[5]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\mattwo}[4]{\left[\begin{array}{rr}#1 \amp #2 \\ #3 \amp #4 \\ \end{array}\right]}\) \(\newcommand{\laspan}[1]{\text{Span}\{#1\}}\) \(\newcommand{\bcal}{\cal B}\) \(\newcommand{\ccal}{\cal C}\) \(\newcommand{\scal}{\cal S}\) \(\newcommand{\wcal}{\cal W}\) \(\newcommand{\ecal}{\cal E}\) \(\newcommand{\coords}[2]{\left\{#1\right\}_{#2}}\) \(\newcommand{\gray}[1]{\color{gray}{#1}}\) \(\newcommand{\lgray}[1]{\color{lightgray}{#1}}\) \(\newcommand{\rank}{\operatorname{rank}}\) \(\newcommand{\row}{\text{Row}}\) \(\newcommand{\col}{\text{Col}}\) \(\renewcommand{\row}{\text{Row}}\) \(\newcommand{\nul}{\text{Nul}}\) \(\newcommand{\var}{\text{Var}}\) \(\newcommand{\corr}{\text{corr}}\) \(\newcommand{\len}[1]{\left|#1\right|}\) \(\newcommand{\bbar}{\overline{\bvec}}\) \(\newcommand{\bhat}{\widehat{\bvec}}\) \(\newcommand{\bperp}{\bvec^\perp}\) \(\newcommand{\xhat}{\widehat{\xvec}}\) \(\newcommand{\vhat}{\widehat{\vvec}}\) \(\newcommand{\uhat}{\widehat{\uvec}}\) \(\newcommand{\what}{\widehat{\wvec}}\) \(\newcommand{\Sighat}{\widehat{\Sigma}}\) \(\newcommand{\lt}{<}\) \(\newcommand{\gt}{>}\) \(\newcommand{\amp}{&}\) \(\definecolor{fillinmathshade}{gray}{0.9}\)4.3 Dealing with Problems
Visit Audio Recordings for the audio version of this section.
LEARNING OBJECTIVES
- Describe standards and procedures for dealing with problems.
- Describe the advantages of dealing with difficult issues as soon as they arise.
- Describe the importance of establishing methods for revising major decisions.
Projects always experience unexpected problems that produce stress. Dealing with problems with competence is vital to maintaining a good relationship with clients.
Establish Standards and Procedures for Decisions
There are competing interests on projects, and the larger and more complex the project, the greater the number of issues and concerns that need to be addressed.
Competing Interests
On large, complex projects, hundreds of decisions are made every day. Most of the decisions focus on the day-to-day operation of the project. Early in the project, decisions focus on choosing between alternative options for accomplishing project goals and determining how the project will be executed. Later, the focus is typically on solving problems. The project team develops solutions to deal with the barriers that emerge and develops alternative plans to meet project goals. The authority to make decisions is typically established early in the project and identified in a responsibility matrix—a table of people and types of problems that might require decisions—as shown in Figure 4.1.
Figure 4.1 The Responsibility Matrix
The responsibility matrix identifies roles and client involvement.
Decisions that influence the outcome of the project, such as a delay to the project completion date or an increase in the project costs, typically involve the client. Some clients prefer to make the final decision, with the project manager developing alternative solutions with a cost-benefit analysis of each of the alternatives. Others prefer to be involved in discussions to better understand the barriers, developing alternative solutions and making decisions in a team environment. Understanding the client’s decision-making preference and developing procedures and processes that support that preference is important to meeting client expectations.
Develop processes and methods that encourage both the client and team members to identify issues and concerns early and develop processes for dealing with them effectively. Define how and when decisions are made.
On projects with a low complexity level, the project manager and team leaders can make decisions informally, with short meetings or phone calls. Weekly or monthly staff meetings are appropriate for more important decisions. Even though the decision-making process may be simpler on less complex projects, it is still important to understand the client’s expectation for inclusion in the decision-making process and recording decisions and changes in project plans.
On more complex projects, the use of action item registers, weekly staff meetings, responsibility matrices, and other tools foster the decision making on a timely basis. For project teams operating in diverse locations, Internet-based tools for recording and tracking action items are beneficial in capturing issues and concerns.
Inform Client of Difficult Issues Early
Project managers typically have a high degree of confidence in their ability to deal with issues and concerns as they arise. Let’s say the delivery of some equipment is delayed a week, causing changes in the project schedule, or the beta test of a software program identified far more problems than expected. If the project manager knows the problems, the project has a plan for recovering, the team developed a solution and will be back on track soon, should the project manager inform the client? The answer seems like an easy yes, yet many project managers often believe there is no reason to bother the client with a problem they have under control.
Then suppose a second delay occurs on the equipment delivery or the fixes for the beta test are more costly than expected. Now the problems have elevated to the point the client needs to be informed. The greater the distance between the time of the event and the time the client knows about the events, the greater the client’s frustration and mistrust. Including the client in the processes for handling project issues or concerns, as well as recovery planning, enables the client to develop confidence that problems will be addressed successfully. Including the client early in the process for dealing with problems enables the client to contribute with solutions and builds confidence that there is open and clear communication.
New Estimates Increase Cost Projections
In the example above, when first indications suggested that estimates were low and several items in the budget needed extra funds, the project manager should have had conversations with the client. Including one or more members of the client’s team in the reevaluation effort would have kept the client informed of the progress regularly and built trust in the new numbers. The project team could have offered suggestions and contributed to possible solutions for addressing the concerns that were developing, as costs were higher than expected. Dealing openly and early with the client is critical to client satisfaction.
Clients are often involved in major decisions on the project. For example, if the project invested another million dollars, the project could be completed a month early. The client will conduct the cost-benefit analysis and decide if the extra expense is worth the gain in time. Once this decision is made, the necessary changes are made in the execution plan and new goals are established through the change management process. Later, for reasons outside the control of the project, the project will not experience the time savings from the additional investment of funds. It is important to revisit the decision. A culture that encourages project team members to bring up the need for revisiting decisions and a mechanism that makes it easy to surface issues and concerns will increase the likelihood that these issues will come to the attention of the management team.
Establishing a culture and a mechanism for revisiting project decisions is important for meeting client expectations.
Emergency Button
Revisiting Major Decisions and Issues
The project environment moves fast, and decisions are made and implemented to keep pace. Decisions made in the conceptual phase of the project may not be effective during the design phase. It is not that the decisions made were necessarily wrong, based on the data at the time they were understandable. However, with new information, it is sometimes important to revisit and change decisions made earlier in the project. As obvious as this might sound, many project teams are reluctant to challenge earlier decisions. Without a mechanism in place to revisit decisions, the early decisions may be seen as final. This sense of finality may limit progress and prevent the project from completing on time, as well as potentially having a project that is irrelevant as soon as it is introduced.
Sometimes people ask that decisions be revisited just because they did not like the decision that was made.
Not Revisiting Decisions
Mechanisms for revisiting decisions are similar to project change orders. With a change order, a request to revisit a decision must be initiated by someone on the team. The formality of methods used by the project to revisit a decision depends on the complexity profile of the project. On less complex projects, an informal discussion in project meetings can develop the awareness that a decision needs to be revisited. On more complex projects, the action item register and the weekly project meetings provide a venue for revisiting decisions.
Vendor Decision Revisited
On a major project creating a new marketing manual for a large university, the priority was completing the manual in time for recruiters to visit athletes and other high school students throughout the country. The client was involved in the process to select major policy wording, and after an expedited bidding process, an instructional design vendor was selected for a critical piece of the manual layout.Later, members of the project team learned that this vendor was overcommitted, and there was a high risk that the vendor would not be able to meet the schedule dates. Even though it was the client’s decision to hire the vendor, the project leadership had established that this kind of issue needed to be readdressed with the client and warned the client of the possible risk and suggested changing plans. The client decided to proceed. Weeks later, the vendor began missing critical dates just as the project team predicted.Since the issue had been revisited, the client took the blame. Changes were made that brought the project back on track and the project finished on time and within budget, making the client even more impressed with the project team.
KEY TAKEAWAYS
- Determine who should be included in decisions for each category using a decision matrix.
- Additional information that is developed during the design and planning phase can require that decisions made during the conceptual phase need to be reconsidered.
- Decide at what level of problem the client should be involved by discussing the threshold with the client. Involve the client early in the process and provide a mechanism to give them a chance to contribute to the solution before the problem gets worse.
- Decide what criteria to use to determine when a decision should be revisited.