Archive for November, 2015

Risk and Communication Management

Posted on: November 29th, 2015 by admin No Comments

Risks and Communication Management

A significant portion of successful project management is due to communication, so it should stand to reason that ineffective communications can be a significant source of project failures.  Everything from evoking scope and requirements, prioritizing objectives, to team building requires effective communication.

Communication is used in keeping the project team in step with the project objectives, as well uncovering previously unknown constraints and adapting to the situations that are presented to the project.  That includes articulating and taking advantage of opportunities as they come available in the course of project execution.

Communication is used in our progress reporting to the project sponsors, we must communicate with our team to and ask questions, define and track metrics to ascertain the progress, and then report that in such a way that the sponsors can understand and take actions we believe are necessary for the project team to remain successful.

We provide a brief list of things that can go wrong in communication management below:

  • undefined areas of responsibility
  • unidentified stakeholders and sponsors
  • false stakeholders acting as stakeholders
  • no or poorly articulated communications plan
  • poorly executed or no escalation plans
  • poor project reviews
  • poorly executed and insufficient project reviews
  • team dispersed across the globe without remediation
  • poorly conducted project meetings
  • no note taking during the meeting
  • no decisions made as a result of meetings
  • unidentified communications channels
  • misuse of (or unaccounted for) informal communications
  • too many communications channels
  • organizational structure complexity
  • no connection between sponsor and areas of priority
  • multiple sponsors
  • no defined method of communication (leaving it to chance)
  • poor listening skills
  • poor recording skills (notes)
  • meeting management
  • team hygiene
  • excessive politics
  • political speak (obfuscation communication)
  • closed environment to open discourse
  • unspecified status reporting periods
  • unknown status report contents (metrics)
  • command and control environment that inhibits open communication

Experience suggests, the complexity of communication often found in conventional projects can be remedied by adopting an agile approach.  Using the an agile approach, the communication channels are reduced and typically collocated.  There are frequent opportunities for communication and the metrics are monitored and constantly reviewed. Additionally, the communication is much more open and subjected to less political pressures, at least if it is done reasonably well.

Many things can derail a project or lead to project failure, and communication is one of them.  Poor communication also exacerbates the risks in the other knowledge management areas.

Risk Management and Failures

Posted on: November 20th, 2015 by admin No Comments

Risks and Risk Management

We continue with our series on the taxonomy of failures in project knowledge areas  looking at risk management. In this case turning our breakdown of the project failures toward risk management.  Risk management is fundamental to project management as we reduce or navigate the potential impediments to the success of our project.  With poor risk management, we may take a project on that should perhaps never be undertaken.  We are not able to balance the risk versus reward equation if we have no idea of the risks.

 

Risk Breakdown

Though this is not so complicated, to be effective requires a diversity of perspectives and thinking.  We can classify risks into three categories[1]:

  • known-knowns – we have pretty good knowledge here, perhaps we have done this type of work before and we have experience, training, and perhaps historical record to help navigate these risks.
  • known-unknowns – we are able to question because we have some knowledge of the area and are aware things can go wrong.
  • unknown-unknowns – we have not idea, we are not able to ask questions about since we have never experienced this risk event

With unknown-unknowns we are talking about the often referred to as black swan events.  Black swan event is a term coined by Nassim Nicholas Taleb used to describe those events that are beyond the realm of prediction without the benefit of hindsight.  There is not much you can do about these.  To be successful here, you would have to theorize the many things that you have never seen happen or heard about occurring.  It is very difficult to imagine that being productive.  The other areas, we either know or we know enough to ask questions.  This questioning is sometimes born from the juxtaposition or extrapolation of ideas and experiences that can occur in collaborative efforts. Effectively executed, we can generate answers or devise ways (tests and experiments) to get the answers.

 

Taxonomy of Risk Failures

Below we provide a brief list of the things that can go wrong in our risk management approach. 

  • insufficient vetting of strategy for the project and product
  • no risk management strategy or plan
  • poorly communicated risk strategy or plan
  • no analysis (statistical) of depending risks
  • insufficient time spent uncovering the risks
  • missing talent within the team to identify risks
  • risk log is populated but never reviewed
  • little or no monitoring during execution
  • failure to promptly respond to team members discussing what they see as a soon to be failure
  • poor use of historical record
  • lack of systems thinking (future consequences)
  • insufficient or no metrics identified for specific risks
  • unknown responsibility for monitoring metric that predicts imminent failure
  • no quantification of risks
  • no qualification of risks
  • risk identification focused on large unlikely events
  • risk identification hyperfocused on easy to solve potential risks
  • insufficient dissemination of previous risks and failures to the team
  • an overwhelming optimism of the team and organization
  • no contingency budget
  • randomly generated contingency budgets
  • contingency budgets not allocated to specific risks
  • hyper focus on one risk category (ex. technical) to the exclusion of the many other areas
  • poor match of risk to risk mitigation (Avoid, Accept, Reduce, Transfer)
  • poorly executed risk mitigation
  • disassociation of risk from stakeholder or sponsor

 

Risk Management Review

There is no panacea or great cure-all for risk management. While not complicated we must not get the idea that this is not important or easy. Successful projects require an active approach to the risks with a mix if imagination and a perspective grounded in reality and not optimism.  Effective planning allows us to find alterative approaches where possible or quickly implement identified actions rather than watching the clock tick and damage to the project and our reputation as we figure out the course of action.

 




[1] NASA administrator William Graham

Risk and Time Management

Posted on: November 19th, 2015 by admin No Comments

Risk and Time Management

In keeping with our last post, we discuss risks due to insufficient time management that often result in project failures.  As is with many things, the symptom of the failure has roots much earlier.  In other words, when we witness the failure, it was due to some event(s) or activities much earlier.

 Risk and Time Management Taxonomy

We provide a brief list of some of the miss-steps we make along the way that will influence our probability of success.

  • formal time reporting
  • organizations time reporting processing
  • overly optimistic task scheduling
  • no accounting for task variance (point source task duration estimates)
  • missing tasks and task dependencies
  • poorly identified and quantified metrics for monitoring
  • poor data collecting for metrics
  • insufficient or lack of monitoring of metrics
  • little or no follow up on the schedule
  • lack of proactive actions taken when the schedule appears to be slipping
  • poorly defined activities including what constitutes success for activity
  • missing expertise in scope decomposition to tasks
  • duration estimated from inexperienced sources
  • poor use of historical record for estimates
  • not adapting schedule based upon performance metrics
  • miss match of plan and tasks to available competencies

 Risk and Time Management Conclusion

There can be little doubt there are many more mistakes we can make that will degrade the probability of success when it comes to project time management.  Our up front steps play a significant role in our success.  This must include identifying key performance metrics (rate of accomplishment and schedule).  We couple this with monitoring these metrics and adapting as we learn the difference between what we thought our performance would look like and what is actually happening and make the necessary adjustments.

Scope Management and Risk

Posted on: November 18th, 2015 by admin 2 Comments

Scope Management and Risk

I would like to thank all of those that attended last night’s experiment with PMChats a live broadcast that will be turned into a podcast.   The topic was scope management and risk, and a brief look at the many areas in scope that can later come back to haunt, or as I like to say, provide a learning opportunity.

A brief Taxonomy Scope Management and Risk

A brief list of the risk of things that can go wrong with scope is provided below:

  • unclear scope
  • poor scope control
  • no configuration or change management
  • insufficient time in planning scope
  • too much time spent arguing over the scope
  • sponsors and stakeholder role and involvement unclear
  • unresolved conflicting perspectives about the scope and no escalation plans
  • inappropriate selection of strategy taken to achieve the scope
  • poor requirements elicitation
  • poor requirements management
  • office politics
  • lack of trade-off consideration
  • poor match of scope to available time and resources for the project
  • rush to produce the final product ( all requirements up front)
  • lack of prioritization of scope contents
  • no confirmation scope has been achieved (verification) until the close of project
  • insufficient team or SME involvement in evoking / understanding the scope
  • unchecked or vetted assumptions

To Help

To help mitigate these risks we:

  • ask questions (sponsors, stakeholders, and assumptions)
  • prioritize scope (what is known)
  • accept and manage change

Of course this is but a short list, we are working on expanding creating taxonomy of risk for the various project management knowledge areas.  We are going to add that to our risk management course we are presently developing.

 

Assumptions and Models in Product Development

Posted on: November 17th, 2015 by admin No Comments

We have recently posted how assumptions, left unquestioned can damage a project. It is similarly true for the product when we use models and simulation to generate our product.  In the course of building these models, we will know some things for certain.  Some attributes of the model we may think we know for certain but may in fact not be valid.

That is why we couple testing with our simulation and models. We will confirm those things we believe to be true and the many things we hope to be true, and probably uncover things we did not even consider to be true through testing.  Those attributes that are connected to the desired outcome, we must understand so we can accurately predict the outcome.  Below find a graphic that shows the process for building and understanding the model[1]:

 

Simulation Process

Simulation Process

 

Assumptions are deadly when it comes to models.  If we believe our simulations and the many assumptions that went into creating are valid and just start building the product we have not learned much through simulation.  We build the models, run real world tests to ascertain the validity and veracity of the models, then update the models with what we have learned from the tests.  Eventually, the models and the testing results converge to an acceptable point where we can confidently generate the final iteration of the product.




[1]  Pries, K., & Quigley, J. (2011). Scrum project management. Boca Raton, FL: Taylor and Francis Group, page 134.

Embedded Development Models and Project Management

Posted on: November 16th, 2015 by admin 1 Comment

Below is an excerpt from our book, Project Management of Complex and Embedded Systems for those that believe the “V” model means single pass product development (as if) – think again!  This book has a significant automotive perspective, complex, highly tooled machines that must meet and government regulations.

Project_Management_of_complex

 

Embedded Development Overview[1]

Embedded software development requires extensive planning, monitoring and thorough follow up to succeed in all quarters.  The responsibility of the project manager is to prepare the schedule for documentation, development, build, and quality assurance.  In order to manage all of these activities and risk, an understanding of the workflow is necessary. The workflow is essentially a model of the production sequence for designing, implementing, and testing embedded software—a map of the process.

General embedded development knowledge and the workflow model allow the project manager to ask pertinent questions. These questions provoke answers about risk from those responsible for the deliverables. Moreover, it allows the project manager to do some risk assessment on his own. Knowledge of acceptable software life cycle processes (via the workflow model) makes it possible to identify situations of increased risk.

There are a number of development cycle models. The project team should reference the same model since this provides a common frame of reference for subsequent team discussions.

  1. Waterfall model
  2. Spiral model
  3. Big Bang model
  4. Iterative
  5. Evolutionary development
  6. V model
  7. Rapid prototyping
  8. Model driven

 

Figure below is an illustration of the ”V-cycle” model for software development life cycle.  The model illustrates how the development starts from a systems level and progresses through increasingly detailed development phases.  The activities start at the upper left hand corner with customer requirements. This customer input drives concept selection and documentation.  Once the team defines the concept, they generate the system requirements that support the concept. The system requirements are broken down to the next level of detail where they document the component(s) requirements (hardware and software specifications). Finally, with the component level documentation complete, the hardware and software design implementation work starts. The output of each block is the input to the next one.

 

V Model Connections

V-Model Connection between Development and Test

 

V-cycle Model

This model provides a juxtaposition of the development work (left side of the “V”), with the verification or testing work (right side of the “V”) necessary to quality secure the product. In the figure each step has related verification to ensure the requirements are satisfied.  For example, design is verified by Developmental tests. The model applies to both software and hardware. During the hardware design stage, performance and functional theories and hypotheses can be tested–verified–to either substantiate or refute an expected quality level.

As with all models, there are limitations with this model.  The “V-cycle” model does not adequately reflect the iterative nature of the development process.  However, with some imagination it is possible to extend the V-cycle graphic to account for the additional phases (refer to figure).

 

Demonstration of Iterative and Incremental Approach

Demonstration of Iterative and Incremental Approach

 

 


[1] Pries, K., & Quigley, J. (2009). Embedded Development Overview. In Project Management of Complex and Embedded Systems Ensuring Product Integrity and Program Quality (pp. 297-299). Boca Raton, FL: CRC Press.

 

TQM Statistics, Control and the Project Manager

Posted on: November 13th, 2015 by admin No Comments

TQM for Project Management- and the PMO

TQM for Project Management- and the PMO

 

Why Statistics and Control Are Important to the Project Manager

More from the TQM and Project Management [1]

One of the purposes of statistical analysis lies in its ability to discern random variation from non-random (or “controllable”) variation. Random variation is extremely difficult to control, although we have seen situations where variance could be diminished through rigorous use of designed experiments. It is much more common for practitioners to move the mean rather than “fix” the variance.

The TQM project manager will want to understand what factors he or she can control and which factors effectively lie outside the domain of project management. When this awareness manifests, project managers begin to have true control, because they are working with those factors that they can, indeed, influence.

Furthermore, the charts can provide a valuable visual indicator to management about what is really going on during the process. The most difficult part of the statistics and control chart approach is finding project material that is amenable to control charts. In our experience, project managers often treat each project as if it were so unique nothing can be derived from experience.




[1] Pries, K., & Quigley, J. (2012). Statistics and Control. In Total Quality Management for Project Management (p. 110). Boca Raton, FL: Taylor & Francis.

Why TQM for Projects and the PMO?

Posted on: November 11th, 2015 by admin No Comments

Introduction

We continue our Total Quality Management for Project Management and the PMO.  TQM can help us with the planning of the project giving us some measure of historical performance from which we can learn. However, it is not just the planning that can be aided by TQM, but also the strategy we intend to take with the project.  If there are things we have learned from our past project strategies, that we have taken a measured approach, we can use these to help understand our strategies true rate of ssuccess.

TQM for Project Management- and the PMO

TQM for Project Management- and the PMO

 

Below is an excerpt from that book. [1]

In the years we have been working, we have seen ample examples of use of hope as a tool for product development and managing project’s in general.  We call it hope, because we make our decisions to produce a certain outcome though we may actually know little about what it may take to be successful.  Even when we do “know” our organization may ignore what is being said to meet this objective. We are not talking about the occasional event where something falls between the cracks.  We are talking about those times when the people around us have been taking measurements to understand the issues and possibilities of that organization.  Instead of building upon this, we summarily dismiss this person that is proving us wrong with this information as not being a team player or just a naysayer with a negative attitude.

A manufacturing engineer will pay attention to the capabilities of his equipment. If, for example, the demanded or needed throughput of product through that piece of equipment is higher than the equipment is capable of producing, some other course of action will be required. It may be possible to adjust the machine – customizing the machine to improve performance. It may be deemed necessary to otherwise upgrade the equipment. Maybe purchase another piece of equipment that meets this new throughput demand.  Maybe the solution is to purchase another piece of equipment and between these two pieces of equipment meet the throughput demands.  The rational engineer will not likely try to force the demanded product through the equipment if the equipment has a throughput limitation and expect all to be well.

Let us consider a product made of a particular type of plastic that has a specific melting point.  It is not likely this product will maintain the features desired or meet the customer’s demands above a certain level of heat stimulus.  It would not seem likely that a sensible person would violate the physical properties of the material and complain about the predictable failure.  The person designing the product would benefit greatly from knowing the attribute of the plastic prior to using the material in a design.

What do these things have in common?  Well, this is exactly the sort of thing that goes on in organizations every day!  This happens in product development and project management.  Many believe that “the old college try” will save us.  Those individuals who point to real data – to show the “reality” are derided as being naysayers; they are not team players.  These people are overly negative.  What does it say for those of the team that ignore the historical record?  The time-honored saying attributed to George Santayana: “Those who cannot remember the past are condemned to repeat it.”

Why TQM Is Important to the Project Manager[2]

Total Quality Management (TQM) involves the application of quality techniques to all segments of the enterprise. We are recommending that TQM be applied to project management also.

Most of the project managers (PMs) we have known have focused first and foremost on the project schedule, next on the project budget, and lastly on the project quality issues. We suspect this approach may even be so topsy-turvy as to be backwards. At no point have we seen project managers applying any sensible quality techniques to their own process. Ultimately, each project we witnessed devolved into a weekly nagging meeting that lasted at least an hour as the PM desperately tried to assert some level of debatable control by doing a futile “time line review.” We know that powerful methods exist to eliminate the flailing usually seen, particularly at the end of the project.

This project flailing may be visible at the end of the project; however, the reasons for the flailing are well before this point, usually in the planning phase.  The TQM tools demonstrated in the following chapters will show how planning that does not derive from past experience is really not planning at all, but going through the motions. TQM and developing a learning organization are tied together.

 

 



[1] Pries, K., & Quigley, J. (2012). Preface. In Total Quality Management for Project Management (pp. xxii-xxiv). Boca Raton, FL: Taylor & Francis.

[2] Pries, K., & Quigley, J. (2012). Chapter 1. In Total Quality Management for Project Management (pg. 2). Boca Raton, FL: Taylor & Francis.

TQM for Project Management

Posted on: November 10th, 2015 by admin No Comments

Below is an excerpt from our book, Total Quality Management for Project Management[1]

Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained, as among savages, infancy is perpetual. Those who cannot remember the past are condemned to repeat it. In the first stage of life the mind is frivolous and easily distracted, it misses progress by failing in consecutiveness and persistence. This is the condition of children and barbarians, in which instinct has learned nothing from experience.

The Life of Reason, Volume 1
George Santayana
1905

 

 

TQM for Project Management- and the PMO

TQM for Project Management- and the PMO

 

Product development is becoming increasingly complex. Technology is advancing. Projects are often populated by a diversity of people in a plurality of locations. Effectively managing these complex projects requires attention to details.  When we understand the range of possibilities for our project’s execution we minimize the risk associated with that project.  We can make plans that meet our typical performance.  Thus we minimize the schedule risks associated with a project that has dates based upon hope and want with little or no basis in reality.  When we drive our people to a schedule that they are aware is a death march, we set them up for failure.

Consider the company management the coach of the team. Certainly like any coach, we will want to push our people to perform better every day.  However, a coach does not push the team to boundaries that the coach knows are not possible. For example, you will not hear a football coach ask his wide receiver to fly in the air for 50 yards. That is not a possible task.  He may, however, see how fast that athlete is, and believe he can get him to run a fifty-yard dash in fewer seconds.  Imagine what we do to the employee morale when we ask them to do what they know is not possible.  Additionally, like a coach, we cannot show our team where we can improve if we do not know how that team presently performs. Further, our game strategy hinges upon what we have for a team. Is our team fast? Is it slow and strong?  We have to either plan our strategy for our organization’s goals, or we have to adapt our present team and playbook to the team we need to achieve our goals. To do so, we must know what we have for a playbook and team. To know what we have for a playbook and team requires measurements and analysis.

This book is about applying those Total Quality Management tools to both the line functions in your project as well as the project management discipline.  You must study your organization to know what really can be achieved.   A fist pound on a conference table with an arbitrarily set date that has no basis in reality may not motivate many people.  While the world is plenty uncertain, we can learn something from the activities our organization performs. We may find out many of the things we assumed valid are not really true. We may find areas of the organization where a little effort will produce great performance improvements. We will have to study these things to find that out and TQM tools are key instruments in achieving that understanding.

The genesis of this book is in part serendipity.  We were setting up a class that merged the discipline of Total Quality Management with Project Management.  We realized we have never seen a book that applies these tools beyond the manufacturing realm.  The more we thought on this, the more we realized while projects are unique, in each organization there are similarities between projects that could help “read the runes” as it were, to improve project future success.  In the text below, we discuss the organization as a project factory bringing the TQM tools into the project management and line management function’s of an organization.  We treat each area in the organization as if it were a station in our manufacturing facility.  An organization’s process can help move the project from “every time is like the first time” to something that is not entirely unique every time.  For example, consider a test department in a company that designs systems composed of embedded (software and hardware) and electrical components.  That department may employ similar tools and will have some set of processes to accomplish the test and verification tasks at hand.  We can critique our past and present to improve the future execution of our projects. At a very bare minimum, we will at least see the range of possible outcomes for the tasks we are monitoring within our organization.  We can use this information to help with the future estimating of projects tasks, while considering that variation that we have seen in those processes and tasks.

 


[1] Pries, K., & Quigley, J. (2012). Preface. In Total quality management for project management (pp. Xxi-xxii). Boca Raton, FL: Taylor & Francis.

 

Agile and Decomposition

Posted on: November 8th, 2015 by admin No Comments

There are limits to the decomposition, and for conventional projects where monitoring may be less routine (meaning not every day), it is in our best interest to decompose as far as possible to make answering any question about the status simple, yes or no rather than some vague estimate of completion (30% complete based upon no real measurement).

In agile we consider the law of diminishing returns (meaning benefit reaped from additional time decomposing and estimating is low) knowing that adapting to the situation is going to be required anyway. We want to break it down enough to gauge what it will take, in as much as a guess can do.  We also want to make sure we do not miss steps, forget elements or the sequence of events.  The project will only spend 4-8 hours of planning in sprint planning.  This will include the team, scrum master and the product owner.  In this meeting we will come to a collective understanding of what constitutes done or completion of an item, as well as refine our estimates via this collaborative discourse.  We will resurrect what constitutes done in the sprint demonstration comparing the delivery to the definition of done from the beginning.

One potential downside of breaking down and choreographing the product to the smallest elements, is that this can give you the perspective that this is the way things must happen.  Some may find it difficult to deviate from the plan.  However, there are probably other ways to achieve the objective of the project.  In agile, the breakdown needs to be sufficient to estimate how much can fit into the sprint.  Since estimating is a guess, and the time allocated for the sprint is relatively short 10-20 days, our team must be cautious not to over populate the sprint.

In summary, the team needs to estimate and populate (sprint planning) the sprint in 8 hours, knowing there is variation and likely parts missing and certainly items that have associated uncertainty.  We will adapt to the circumstance as we learn in the project.

Single Sign On provided by vBSSO