Category Archives: Project Management

  • -

Do You Have an Emergency Contingency Plan?

Category : Project Management

I recently came across a fascinating, if frightening, story on LinkedIn that looked at the dangers of airlines running software on legacy code.
 
For the uninitiated, legacy code is the term given to original software code underlying a system. It’s usually of some vintage and in many cases the original coders are long gone. But it’s typically good sturdy code, revised and strengthened over time.
 
The problem is these systems are tied to underlying code and programming languages that are usually a relics of another era. COBOL, for example, was a common coding language in the internet’s infancy but practitioners of it are hard to find today.
 
It’s a great article. But what made me sit up and take notice was an example of airlines and the emergency system plans in place for an outage or emergency.
 
Simply put, most airline booking systems didn’t have one and in the three scenarios noted in the article all three paid the price for not having a contingency plan in place. 
 
In the project management field, having contingency plans in place is absolutely essential. Can a contingency plan prevent an outage? No, but it can mean the difference between a long system outage and an extremely short one. And that time can be measured in dollars, cents and customer frustration.
 
To talk to us at KSP Partnership about how we can improve your business processes including emergency contingencies, please get in touch.


  • -

Back to Basics

When you work with organizations to help accelerate the productivity and profitability of their project teams there are questions that keep coming up:

‘So this is project management, right? Do you teach scheduling or something?  Can you fix our project management application?’

The long answer is that we work with teams and they become more productive because of how they work together rather than the tools they use as they work together. Project management is the cloak that covers the down and dirty business of changing the behaviors and dynamics within the team.  This is because, as a seasoned project manager, there is an assumption that underlies each team.

The assumption is that they already know the basics of scheduling, estimating and risk management. Well……you know what they say about assumptions.

Regardless of whether you use Agile, eXtreme Lean, Six Sigma or Prince2 as an approach there are some things that remain true.

You need to be able to communicate to your stakeholders.

  • How long will it take?
  • What will it cost?
  • When will it be done?
  • Why might it fail and what can we do about it?
  • Are there possible opportunities to wring other benefits from this work aside even from the stated goals and objectives of this project?

Sometimes you find that even your most fundamental assumption is groundless.  Sometimes you find that, under the extreme time pressure of an ever-faster pace of business, people have lost-forgotten-abandoned some of the basic tools and approaches that would serve them well.

With that in mind, I am delighted that Michael Bender has taken on the challenge and has begun the task of creating micro-lessons – called uLessons on YouTube. These lessons will be taking you back to the basics.  No lesson is very long – you could probably take one or two in and still have time for coffee.

Teams that are on the way to becoming more productive will still actively consider the value of their tools and approaches.

And there are times when a refresher isn’t a bad idea.

Your tip for today: Having the whole team view and discuss the topics of Michael’s uLessons is also a great way to build both Clear Definition and Collaborative spirit. These are two of the four foundational Key Success Parameters. Use this discussion as a way of confirming how your team members each develop their estimates. Is there a best practice that could be standardized? Who on the team can help each other?

So the short answer is ‘No – this isn’t just project management. It’s about how to get your teams to project success.’

If you have a project that is not meeting expectations for two reporting cycles – or more – let us help with our diagnostic and discovery process.


  • -

How Much Time Does Your Team Actually Spend Working?

Category : Project Management

How much time does your team actually work during the day?

In live seminars, I run a quick survey of team productivity. I call it the “Other Stuff” list. It’s a list of all activities individuals do during the day that is not project work. I then ask students how many hours they spend on a typical week doing each of those activities. After 20 years of running this exercise, I’m still amazed at the results.

I encourage you to run this exercise with your team or colleagues. Take a white board, flip chart, or simply a piece of paper. Ask your team to list all the activities they do during the day for which they get paid. Then, ask them how much time they spend in a typical week doing each of these activities. For daily tasks, ask how much time they spend during the day and multiply by 5. For yearly tasks (vacations, holidays, etc.), divide by 50 (or 52 if you want to be more precise). Remember, it should only include activities for which they are paid. For example, if you’re paid for lunch, include it, otherwise, don’t. Here’s a sample list:

  • E-Mail, Voice-Mail
  • Meetings (non-project meetings)
  • Biological needs (coffee breaks, etc.)
  • Social needs (chit-chat)
  • Training
  • Your “real” job
  • Firefighting/Emergencies
  • Equipment problems (computer problems)
  • Mentoring, helping out your colleagues
  • Vacation, holiday, sick
  • Travel

If you’d like to see how I do it, play my short video on Estimating Basics, Micro-Lesson 1. I think the results will surprise you as well.

May all your projects be successful!

Michael


  • -

Managing Task Interdependencies – Building a Culture of Performance

Managing Task Interdependencies

The Challenge

Managing task interdependencies is one of the most challenging aspects of project management. A recent study indicated that 70% - 80% of project changes can be attributed to internal (and controllable) issues, not client issues. Consider the following diagram:

Figure 1: Project Precedence Diagram

Most project managers will recognize this as a precedence diagram or PERT chart. Each node represents an activity within the project. In essence, it’s a work-flow diagram. Once the project starts, tasks A, B, and C can start and each can run in parallel. Task E requires the outputs of A and B. For example, task A might be surveying a plot of land to create a plat. Task B might be laying out the overall structure of a house. Task E might be locating the house on the lot. Errors or omissions in task A or B, therefore create problems in task E. In order for the team conducting task E to complete their work, they must re-engage team A and team B to resolve the issue.

Now, consider that any error or omission isn’t discovered until task Q. Issue resolution now requires engaging many of the previous teams, creating a large number of project changes.

The effects of these issues can be easily identified in a variety of ways:

  • Large number of changes found toward end of a project
  • Team members spend more time addressing issues, getting questions answered, or gathering information than they do performing the work
  • Frequent “emergencies” to address issues to get a product out on time
  • Project delays increase as the project proceeds

In its simplest form, ask yourself how many times you go to your favorite home improvement store to finish a home project (upgrade a closet, finish a basement, remodel a room, etc.) The common element in all these effects boils down to managing task interdependencies.

The Lexicon

The discipline of project management, like all disciplines, consists of a set of esoteric terms which may not be obvious to all readers. To address both formal project managers and the general readership, we define the following terms:

Task or Activity:  A specific action that creates a deliverable, result, or work package. Formal project management defines a work package[1] as a well-defined component of a deliverable. Activities (or tasks) represent the steps needed to create the work package.

Predecessor:       Task or activity that precedes (comes before) another activity. The result of the predecessor becomes the input to the successor.

Successor:           Task which follows another activity.

Deliverable:         The artifact that is transferred to the successor activity. Sometimes called the result.

Why are Task Interdependencies so Challenging?

Projects are likely the least understood of the work endeavors performed in organizations in both the fields of practical management and academia. Unlike other organizational endeavors, projects form a complex network of activities as depicted above.

If you have an MBA, you may have studied the subject of Task Complexity. While several models of task complexity have been offered over the last few decades, most fail to address the characteristics of complex networks (e.g. projects) (Haerem, Pentland, & Miller, 2015). Charles Perrow, for example, divided activities into four categories based on task variability and task analyzability (Jones, 2013). James D. Thompson (Jones, 2013) developed the theory of Task Interdependence. This theory categorizes organizational work based on the interdependencies of tasks needed to convert inputs to outputs. One such category is called Long-Linked Technology which is based on sequential interdependence.  Thompson’s model suggests linear dependencies such as those found in production lines or business processes. In sequential interdependence, the output of one task becomes the input to the next task. The results of the first task, therefore, affect the performance of the second task (a domino effect).

While Thompson (Jones, 2013) and others recognize the domino effect of task interdependency; projects, by their nature exhibit a greater degree of complexity than seen in sequential interdependence. Haerem, Pentland, and Miller (2015) recognized the consideration of task antecedents regarding task complexity, expanding this view.

Simply put: sequential interdependence suggests that each task has a single predecessor and a single successor. However in projects, tasks have multiple predecessors and successors. In sequential interdependence, problems grow linearly as they move through the endeavor. In complex interdependence (e.g. projects), problems grow exponentially.

Managing Task Interdependence

Managing task interdependence is simple in form, however it requires a high degree of rigor. First, we consider the form (using a step-by-step analysis), second, we consider the rigor.

Managing Task Interdependence – the Steps

Step 1: Start with a complete list of activities

Most project managers are familiar with the Work Breakdown Structure (WBS). The project manager works with the team to create a complete list of activities for the project. Creating a WBS involves decomposing high-level deliverables into specific steps (or activities) needed to create each deliverable.

It is beyond the scope of this paper to present the details of either the activity of creating a WBS or its characteristics. For the sake of this presentation, we simply assume that the WBS creates a COMPLETE list of all activities needed to complete the project.

Step 2: Identify the Predecessors and Successors of each Activity

The project manager works with the team to determine what each activity needs to start. Using our previous example, we ascertain that determining where a house will be located on a plot of land will require the outside dimensions of the house and the plat of the land. Certainly, it also might require more inputs, such as the building requirements regarding the buffers needed between the building and edges of the lot. The project manager employs the expertise of his/her Subject Matter Experts (SMEs) to establish all the needed predecessors (inputs).

Step 3: Determine the Complete set of Requirements of Each Activity

Once the predecessors and successors have been established, the team SMEs must clearly define each activity. This includes determining the specific requirements that each predecessor needs to ensure the following-task performers have all the correct information they need. This step, perhaps is the most challenging within the framework. The activity requirements must meet two conditions:

  • Succeeding tasks need to have all the information and artifacts needed to complete their tasks
  • Activity requirements must support the ultimate customer’s requirements

Several tools exist to aid in development. One such tool is the Goals Breakdown Structure or GBS (see The Goals Breakdown Structure later in this document). Another common tool is called Requirements Traceability.

Step 4: Execute the Activity

Once the activity is well defined and contains all the requirements needed to satisfy both the customer and succeeding tasks, the project manager assigns a skilled team member (or members) to perform the activity.

During this step changes may be discovered. Requirements may be inaccurate or incomplete; or technical, design, or scheduling issues may arise. As they do, these need to be immediately communicated to both the project manager and succeeding task performers.

This is a crucial part of execution. This resolves issues quickly and at minimal cost ensuring a smooth project flow.

Step5: Ensure Rigorous Quality

Ensuring rigorous quality classically involves two sub-steps: unit testing and peer reviews. As each task completes, the task performer, with the aid of others, ensures that each task requirement has been met. The task performer first runs unit tests to ensure all requirements have been met. While necessary, unit testing is insufficient. Have you ever tried to proofread your own documents? Generally, you’ll manifest the same mistakes testing the results as you made in creating the results.

The next sub-step is a peer review. Peer reviews bring extra pairs of eyes to the results to ensure compliance. Peer reviews not only ensure all requirements have been met, they also allow the team to exchange best practices.

Step 6: Transfer the Results and Report Discrepancies or Changes

Once the peer review is complete, the task performer transfers any changes along with the task results to all the succeeding tasks, and completes their administration (recording actual times and costs, and handling any other administrative activities).

This completes the task.

The Goals Breakdown Structure

Breakdown structures simply are hierarchical decompositions of larger items into smaller items. Most project managers are familiar with the Work Breakdown Structure (WBS). With the WBS, project managers with help from their team members, break down higher level activities (or deliverables) into smaller activities (or components of deliverables).

Goals exhibit the same hierarchical characteristics (Juran & Gryna, 1988). For example, to build a table, one must first determine the overall characteristics (requirements) for the table (size, height, finish, weight requirements, etc.) Then, one can determine the characteristics of each component of the table (size and shape of the top, legs, etc.). The lower-level characteristics must align to ensure the completed table meets the higher-level characteristics. For example, the length of the legs plus the thickness of the table top must add up to the overall height of the table. The legs must be finished the same way the top is finished, etc.

In projects, there are at least four separate layers of hierarchy. These are:

  1. Overall goal of the project
  2. Organizational objectives
  3. Product requirements
  4. Component specifications or requirements

Larger, more complex projects may exhibit more layers, but we’ve found in our experience that these four layers do nicely for most projects. Consider figure 2.

Figure 2: Hierarchy of a Goals Breakdown Structure

The top layer is the primary mission or goal statement for the project (frequently called the Project Statement). Example: Create a beautiful dining room table to entertain 8 – 12 guests in a formal atmosphere.

The next layer is the business objectives. These include (typically) 5-7 measurable (if possible) goals the business desires the project to achieve. These are typically represented in the organization’s strategic plan.

A partial set of business objectives for the table project may include:

  • Table shall be a classical “old world” style
  • Table shall allow for a minimum seating of 8 people and a maximum seating of 12 people
  • Table shall cost no more than $4000
  • Table shall be ready for service by 11/17/18
  • Table shall resist staining from hot (180o) or cold (10o) plates placed directly on the top

The third layer is the project’s requirements. These include a (usually) large number of both product and project requirements (or characteristics) needed to meet the business objectives. These are created by the customer and the performing organization’s business analyst. A partial list of requirements may include:

  • Table shall be made of mahogany
  • Table shall be prepared with no less than 4 coats of polyurethane
  • Table shall be 12’ long x 3’ deep x 2.5’ high ± 1/8 inch
  • Table shall be able to support 400 lbs.
  • Table shall provide for an extendable leaf of 3’ x 3’

The last layer of the GBS contains the specifications or requirements of the individual tasks within the project. These are developed by the technical staff or SMEs. Specifications for the legs must take appropriate higher-level requirements into account. Assuming the thickness of the table top is set at ¾ of an inch, a partial list of component (or activity) specifications for the legs may include:

  • Legs shall be 2’ 11 ¼ inch in height ± 1/16 inch
  • Legs shall be mahogany
  • Legs shall be prepared with no less than 4 coats of polyurethane

As one can see, certain changes in the manufacture of the top may affect the legs. Using a simple example: if the team building the top discovers that they can’t use a 3/4 inch top, the height of the legs must be adjusted accordingly. If this issue is not communicated, the result will be a table of the wrong height, causing rework and potential “emergencies” at the end of the project.

The Issue of Rigor and Culture

Initially, the level of rigor needed for successfully managing a project may seem onerous. However, our research suggests that this issue is more about culture. Several pockets of cultures exist where this level of rigor is the norm, it’s just the way things are done. It’s habit, it’s standard, and it’s in the threads that bind the organization.

In such organizations, goals breakdowns are part of every design. Aligning lower-level requirements to higher-level requirements are incorporated within each project (in US government contracts, the process is called Requirements Traceability). Peer reviews are commonplace. Changes are immediately communicated to management and adjacent teams.

Such organizations complete projects faster and with higher-quality by eliminating the confusion, frequent interruptions, and problems associated with many projects.

Focusing on cultural improvements that align with productivity can substantially improve organizational productivity. These cultural characteristics (called Key Success Parameters, or KSPs) become the basis of designing a high-performance organization. In such organizations, managing task interdependency is not onerous, it is a norm, it is habit. A brief description of each KSP follows:

  • KSP 1: Clear Definition

Staff and management habitually clearly define the requirements of specifications of each activity within the project. They ensure requirements trace up to meet customer’s requirements and ensure all succeeding task performers have all the information they need to complete their tasks.

  • KSP 2: Ownership

The project manager assigns an individual who is responsible and accountable for the successful completion of each task, for communicating changes in schedule, cost, or requirements, and ensures all requirements have been met.

  • KSP 3: Customer Focused Deliverables

Team members ensure each activity’s requirements align and support the customer’s deliverables.

  • KSP 4: Collaborative Spirit

Team members proactively engage each other to communicate changes, resolve issues, and efficiently complete each activity.

  • KSP 5: Task Interdependencies

Project managers and staff proactively manage and communicate issues that affect adjacent tasks.

  • KSP 6: Rigorous Quality

The task owner ensures that they meet each requirement through unit testing and peer reviews.

  • KSP 7: Risk Management

Project managers and staff proactively address possible risks, communicate and manage risks as they occur to ensure smooth project flow.

Summary

Projects consist of a complex network of interdependent tasks. Each task may have multiple predecessors and multiple successors. Changes and quality issues in one task can have an exponential effect on tasks downstream. The longer issues remain unmanaged, the greater the impact on the project’s cost, schedule, and quality.

When properly managed, each activity within a project must be clearly-defined with measurable specifications. The results of each activity need to be verified to ensure quality. Changes that occur during activities need to be communicated to both management and downstream tasks owners to ensure issues don’t propagate.

Managing task interdependency can appear onerous. However, manifesting a culture of clear definition, rigorous quality, and communication will build teams that complete projects faster and with higher quality.

References

Haerem, T., Pentland, B. T., & Miller, K. D. (2015, July). Task complexity: extending the core concept. Academy of Management Review, 40(3), 446-460.

Jones, G. (2013). Organizational theory, design and change (7th ed.). Upper Saddle River, NJ: Pearson Education, Inc., as Prentice Hall.

Juran, J. M., & Gryna, F. M. (1988). Juran's Quality Handbook (4th ed.). New York, NY, USA: McGraw Hill, Inc.

 

 

[1] In formal project management, precedence diagrams are built from activities, not work packages. Therefore, this paper focuses on activities rather than work packages.


  • -

3 Top Ways You can Tell if Your Team is Working Well

3 Top Ways you can Tell your Team is Working Well

  1. Lively – sometimes even contentious! – discussions about the requirements and the stakeholders
  2. Spontaneous peer reviews
  3. More conversations

Number 1 seems to invite revolution – it doesn’t. When teams are coming together in true collaborative spirit to get very clear definitions of work required and the circumstances surrounding it, you will hear it.  Sometimes it’s pretty loud.

And that’s a good thing.

Because questions and answers on topics that matter to the questioners and answerers can get loud.  That’s great – as long as loud doesn’t signal antagonism or bad behavior.  A spirited conversation that teases out what they really meant is a good way for team members to learn constructive communication habits.  Asking, and getting answers, and finding that it’s quite safe to do so can result in greater creativity and more innovative thinking.  Remember the last time you shared an idea with a trusted colleague? Did you ever have the experience when the very act of sharing the idea prompted your mind to tweak it, shift it or change it?

Spontaneous peer reviews indicates that the requirements are clear and technologists and the other professionals on the team are willing to work together to achieve them. It means that the focus has shifted to rigorous quality and away from ‘keep your head down and off the radar’.

More conversations will sometimes start as simply more noise – don’t let that fool you.  As your team builds the levels of internal trust you will find that they, like so many others, will begin to develop team-speak. Team-speak is a kind of short-hand that relies on the ability to trust each other. Combine that with a focus on both clear definition of the subject at hand, and always keeping the customer in mind as the deliverables are crafted, and you’ll have a powerful team dynamic that delivers quickly, well, and with less overall stress.

Which one of these are you seeing in your environment – in your teams?

Encourage open discussion and reward the candid questions that seek to clarify.

Introduce peer review practices on small pieces of work at first. This gives the team members a chance to experience it, see the impact it makes to improve the work product, and grow the productivity level of the team.

Encourage conversation outside of status meetings and formal hand-offs.  Encourage or even direct (at first!) peer to peer conversations when questions arise.  This builds intra-team communication practices and higher levels of trust.

And you can start seeing the 3 top signs that your teams are more productive!

3 Top Ways your Teams can Dive into the Muck of Mediocrity

There is a lot of nodding but not conversation in meetings.

Peer reviews are being rescheduled, postponed, or resisted entirely.

Hand-offs between colleagues signal the first contact between team members other than project meetings.

Kimi Hirotsu Ziemski, MBA, PMP, CSM

 

 


Upcoming Events

  • Private Client August 27, 2018 San Francisco, CA, USA
  • Private Client August 28, 2018 San Francisco, CA, USA
  • Private Client August 29, 2018 San Francisco, CA, USA
  • Private Client August 30, 2018 San Francisco, CA, USA

Newsletter