Successful project delivery using Quality Management Plans (QMP) – and happy customers!

We’re often asked by project managers about the purpose of Quality Management Plans and what benefits (if any) they may have on projects.Screen Shot 2015-02-04 at 11.55.27 am

The short answer is that when used correctly they can be essential to project success.

Firstly what is a Quality Management Plan (QMP) for a project? (they’re often also called Project Quality Plan)

We’ve provided a QMP  you can use here.

Just as a Project Management Plan (PMP)* describes the project objectives, strategy, activities, mechanisms, constraints and resources for a project, a QMP is a document which describes the:

  • quality objectives
  • strategy
  • methods,
  • standards and
  • assurance activities

to deliver an agreed level of quality for the project.

*the QMP/PQP can (and often is) included as a chapter or section within a project’s PMP

Quality Objectives
These seem to cause the most angst for project managers.  These are just the specific goals and targets for the project deliverables. eg. Zero software defects, <5 non-critical external asset material problems, zero Health/Safety/Environment issues.

Once the objectives have been defined, a strategy to achieve those objectives needs to be described – what is the overall QC/QA/method to be applied? Lots of upfront design reviews? Daily walkthroughs? Inspections scheduled throughout the project?

Quality Controls
The Quality Control for each phase and each deliverable (or type of deliverable at the very least) needs to be described in sufficient detail so that the project stakeholders have a reasonable understanding of what is being undertaken.

Testing & Defect Management
If there is no separate test strategy, you need to describe how defects, problem reports, and other non-conformances are to be managed on the project. So the process/mechanism for:
• Identifying defects
• Prioritizing defects
• Reporting defects; and
• Resolving them
needs to be described. Of course if there is a test strategy which describes this then it doesn’t need to be repeated.

Process Non-conformance
The QMP should also include processes for addressing process non-conformances. What happens if team members don’t follow the agreed process for the project? How will this be identified? (see the next section) What impact will it have on the quality of deliverables (products and services)?

Process & standards compliance (audits)
The review of compliance to required processes and standards needs to be described. Process assessments enable a reasonable level of transparency and visibility are available to the sponsor and project stakeholders in a timely manner. After all, getting details of poor design practices once manufacturing has commenced is a wasted opportunity.

Some indication of which process reviews or audits are to be undertaken needs to be described. The questions of what will be reviewed, why and when should be answered.

Project-specific processes
Unless described elsewhere (and it often isn’t) the QMP should include all project-specific processes. On many contracts there are specific processes which are unique and need to be followed, so it’s important to inform project team members of any special requirements.

Customer Complaints and Feedback
Customer complaints are often seen by project managers are the bane of their existence. If customers would only stop complaining the project team could get some real work done.

However if you broaden the term to include both positive as well as negative feedback you’ll tend to get a much more positive response from the project team and customer. But in doing eliciting comments and feedback from customers and partners, you must provide a mechanism to ensure positive comments are actually collected.

  • What needs to be described?
  • How will feedback be collected? Surveys? Email?
  • How often will feedback be collected? Monthly? Quarterly? Find a balance.
  • Who gets to see the raw data? Everyone thinks they want the raw truth – until they see in the light of day.
  • Get gets to see the results
  • What actions will be undertaken to address the feedback?
  • Who is responsible for each action?
  • How will corrective actions be communicated back to customers, partners and stakeholders?

Quality Gates and Acceptance Criteria
For a project to progress through differing phases, most projects conduct project quality gates (also called quality review points, checkpoints, etc). These gates ensure mandatory activities/criteria are satisfied prior to subsequent phases occurring. They are also the best mechanism to examine the progress and performance of a project to assess whether it should continue or whether some action is required.

The QMP should include as much criteria as possible for each of the quality gates. Preferably include the actual quality gate checklists that will be used (with the understanding that they may be tailored/adjusted prior to the gate occurring once more information is known about the project). This will ensure that no “unknown unknowns” are raised at a meeting surprising everyone and frustrating the project manager.

Supplier/Partner Quality
The QMP should also include how the quality of deliverables from suppliers, subcontractors and partners will be managed.

Although often included in contract terms and conditions, they are often not described in sufficient detail to be useful.

  • Who is responsible for QA/QA?
  • When will it be conducted?
  • How will multi-supplier conflicts be managed?
  • Who will pay for defect rectification prior and post delivery to the customer?

Agreeing these mechanisms jointly with your suppliers and partners will ensure everyone’s expectations are aligned (or at least known).

Standards
Finally the standards which need to be followed must be specified. This can be in the form of an appendix or end section. It’s interesting to note that this is often left out of QMPs and contract documents. Or it’s included in a brief clause stating that “appropriate” standards will be complied with. This can be a major source of conflict due to inferences drawn from poorly specified standards requirements.

Summing up
The QMP should be approved at the same time as the PMP to ensure both documents are aligned. (which will definitely happen if the QMP is a section of the PMP)

Once approved, the QMP contents should be communicated to project team members and all appropriate stakeholders to ensure a consistent view of quality expectations for the project.

Just like the PMP, the QMP should be updated at appropriate junctures throughout the project. And just like the PMP, the QMP often isn’t.

Agile and the QMP
While many people believe the PMP (and hence QMP) to be anathema to agile development, the QMP can be a powerful force for agile development projects.
But that’s for the next post.

Advertisements
Posted in Uncategorized | Tagged , , , , , | Leave a comment

Criteria for selecting a development method – Agile, Waterfall, Agifall hybrid

Why did you choose the method you’re using right now?treasure-map-153425_640

We’ve all been in the scenario where the old way of developing has become stale. Productivity is down, defect rates are rising, and team morale is low.  Things may have been chaotic recently and work practice quality has slipped and shortcuts taken.

Before throwing out the old method and simply choosing the latest Agile method, you need to take the time to define your selection criteria carefully.  Just choosing whichever method is currently making the social media rounds is not always your best approach. Deployments of new development methods often fail because they are just not suitable for the team/project/technology/customer.

Before investigating and choosing a method, define your critical criteria. What should the criteria look like?

  • Size of the team (and the company)
  • Geographical colocation or spread out across offices and countries
  • Average experience of the developers
  • Average tenure of the developers working together in a team
  • Stability and visibility of requirements
  • Level of customer involvement/engagement
  • Need to predicting/estimating cost, effort
  • Importance of milestones and gate reviews to the customer and contract
  • Time to market needed for a minimum viable product
  • Effectiveness of comms
  • Level of developer interest in the new method

Each of these can have a significant impact on the success of your method deployment. Getting them right (or at least good enough) must the first priority for your development change effort.  It can mean the difference between success and bankruptcy.

Posted in Uncategorized | Leave a comment

10 questions for effective Retrospectives/Post Implementation Reviews

Screen Shot 2015-09-28 at 10.41.13 pmIf you run retrospectives and don’t find them valuable, then read on…

Any organisation that has existing for more than a few years will have run a number of projects and (hopefully) retrospectives/post implementation reviews. The effectiveness of these activities tend to flatline after a while. How can you measure their usefulness? How can you get more value from them?

Ask yourself the following:

  1. Are retrospectives normally conducted? Or are they reserved for projects that fail badly?
  2. Is the purpose of each retrospective known? Or are they perceived very differently between stakeholders?
  3. What result do they bring about? Is this in line with the established purpose(s)?
  4. Do the same issues get raised again and again?
  5. Are most of the suggestions from one person? Do the suggestions come from everyone or just management?
  6. Are the issues and hence positive and negative issues addressed in actions? Who follows them up? Or are the reports shelved?
  7. Are the sessions a talk fest? or do they focus on specific, relevant issues?
  8. Do participants come prepared with examples and data? or do they simply offer opinions?
  9. Do the sessions suffer from presenteeism?
  10. Can you list 5 improvements undertaken in the last 3 months that originated in retrospectives/PIRs?

Why are these questions important? Because retrospectives/PIRs are one of the major sources of improvements an organization has. If they aren’t effective, you are likely missing out on significant improvements to your bottom line.

You can’t improve everything at once across a company, so prioritize a project improvement mechanism – the retrospective.

For ideas on how to solve these problems and improve your retrospectives/PIRs, see my previous posts here and here.

Posted in agile, alignment, attitude, checklist, Effectiveness & Efficiency, executive, improvement, organization change, people, PMO, problems, process improvement, productivity, project management, quality, ROI, strategy, structure, templates | Leave a comment

How to run effective customer/supplier (SCM) quality meetings

I was recently asked about how to run effective customer/supplier quality meetings.  I’ve been on both sides of the table representing small and large, simple and complex products and projects.

What is the best way to run them?  That depends on what result you want from them.  They can be run for a variety of reasons:

  • establish a new working relationship
  • sort out a problem or address a conflict
  • gain an understanding of anticipated situations and risks
  • deal with changes in management and technical staff (on both sides)
  • deal with changes in development or manufacturing processes, or other interaction points
  • establish baseline of performance to (re)negotiate and inform commercial arrangements

It is critical to establish the expectations of both sides up front.  If you’ve not clearly defined these expectations and mechanisms, the you’ve got some significant problems and risks – but that’s a whole other post.

Assuming that you have regular customer/supplier meetings (if you don’t have them, start now), what should be covered?

Though the amount of time and detail will differ depending on whether it is

  • off the shelf products/services
  • new bespoke product
  • changes to existing products
  • integration/coordination between multiple suppliers

Essentially the same topics need to be covered, but may also differ based on whether:

  • it is a project and which phase of delivery
  • it’s an ongoing supply

The following can be used for both an agenda as well as a report structure:

  1. Contractual requirements and any clarifications (managing expectations)
  2. Variations – either contractual or implied
  3. Performance – deliver on time (quantities, milestones, etc)
  4. Quality performance – within established upper and lower quality/defect levels
  5. Key trends and whether thresholds are being broken (or a headed in that direction)
  6. Tests, inspections, V&V to date, what went wrong and what is needed to improve
  7. Changes to critical/strategic subcontractors
  8. Changes to development, manufacturing and delivery/operational processes
  9. Results of internal and external audits
  10. Root cause analyses and actions from these
  11. Other improvement actions from issues, problems, defect trends
  12. Customer satisfaction survey results
  13. Evaluation of quality reporting, communications and engagement – are they sufficient and effective for both customers as well as suppliers?
  14. Issues identified by the project teams (both customer and supplier sides) that are impacting development, delivery or risks to future activities

Having a brief report which is streamlined around the agenda will enable data to be collected prior to the session and for stakeholders to focus on the critical areas.

This may sound daunting and time consuming but it can be streamlined with:

  • these topics being articulated in the contract or work statement
  • data collected prior to the meeting
  • keeping an agenda that only focuses on what is time/phase relevant

In doing this, a customer/supplier quality meeting can be conducted in 30-90 minutes (often tacked on to a project meeting).  Any longer than this and you need to break it into multiple sessions around areas/issues.

During or right after you’ve run the meeting simply update/annotate the report with any actions and points covered in the meeting.  This keeps paperwork to a minimum (after all who wants to have an agenda + a meeting report + a report, when you have one document do all of it).

Always remember that in a perfect world all customer/supplier meetings should be mutually beneficial.  If you have an adversarial customer or supplier across the table, you will need to adjust the topics to suit the type of discussion you are likely to have.

Unless there is a commercially or legally disadvantageous reason, the customer/supplier relationship should be as open and transparent as possible.

Remember it’s an education for both sides.

Posted in audits, checklist, Effectiveness & Efficiency, improvement, KPI, people, PMO, problems, process improvement, product quality, project management, quality, risk, software quality | Tagged , | Leave a comment

Planning for a productive retrospective – key challenges

What are the key challenges to using Retrospectives/PIRs to improve?  The challenges are legion are broadly fall under two main themes:

  • Duck & cover
  • Technical/procedural

Duck and Cover

a) A general reluctance to do it – “We don’t want to do it because the project didn’t deliver, went poorly, cost too much, and we’ve heard heads need to roll.  This can be the result of a toxic culture and can only be resolved by sponsors, execs and senior managers communicating and promoting the value of Lessons Learnt – and not laying blame as the first resort.

b) “We don’t have time to do it” – this often has the same cause as a) but can be overcome through some prep work prior to the Retrospective session, and then shortening the session to an hour or two.  In any case Retrospectives/PIRs are rarely effective when held over two days.

c) “we’re unique, it’s only relevant to this project and no one else would be interested” – again this often results from fear and needs to be addressed by sponsors/execs/senior managers communicating the need to learn and improve through these sessions.

Even the most specialized projects can be a source of improvement opportunities to establish what worked, what didn’t and what we can do next time.

With any Retrospective there will be communications – use these comms to establish guidance on what type of lessons the team/organization is looking for.  Keep them based around PM, technical, and managerial issues and you’ll get a much healthier response.  Leading by example is the most effective and visible means for sponsors and PMs to demonstrate their commitment to a valuable and productive process.

Technical/procedural

The other theme is technical and procedural/method issues.  These need to be considered and addressed:

1. Scope – how broad should the review go? Should it include just the immediate core project team? or should it involve business SMEs?  What about suppliers? Customers? Other internal and external stakeholders?

Consider the potential benefit for inclusion of each group and weigh it against the problems caused by too many participants and stakeholders watering down the review by wasting time on tangential issues.

2. What to collect – Use a (simple) template to guide the collection, preparation and structure of Retrospective/PIR.

Using a template that is streamlined as possible will enable participants to focus on the critical items.  To determine how much detail to include, simply assess what actions could come from it.  The more tangible and specific the issue, the more likely it is that an action/improvement could be undertaken.

3. How to make it available – The worst deliverable from a Retrospective/PIR is a lengthy report that gets presented to management which is then filed.  

All that is needed is a simple summary of the issues and links to actions/improvements.  It is these actions/improvements which are the real value from Retrospectives.  These could include things like:

  • improve PMP template to include risk budget
  • develop checklist for mid project customer review
  • include product development component in every project budget
  • develop reusable customer satisfaction checklist based on the one developed in the project

4. How to focus on positives and negatives

In the typical post-project blues most participants focus solely on the negatives.  No real thought or time is given to analysing the positives.  

Use the template to drive both positive and negative observations.  Allow equal space for both and give specific examples of both positives and negatives in the template to prompt participants in both directions.

5. How to manage conflicts

As with any meeting, conflicts and disagreements will inevitably arise.  It is critical to establish and communicate prior to the session an agreed mechanism for resolving conflicts.  Reiterate this mechanism at the beginning of the session to ensure everyone understands the bigger picture of improving the organization.

If an argument cannot be resolved using the standard mechanism, it may be better to postpone or incubate it to ensure time is not wasted that could be better used on improvements.

6. Differences in preference

There are numerous methods, techniques and approaches to conducting Retrospectives.  Likewise there are a plethora of preferences that participants may have (which may change over time).  Try and match the approach you select with the maximum number of participants.  Include some variety during the session if possible to cover other preferences.

Explicitly examining preferences and your approach will maximize the likelihood of success and value to the organization.

Retrospective on Retrospectives

One last point – regularly examine the performance of the teams when performing Retrospectives – what worked and what improvements could be made.  Plan and schedule improvements so that Retrospectives can themselves be source of learning.

 

Posted in agile, alignment, attitude, checklist, Effectiveness & Efficiency, executive, improvement, innovation, method, organization change, people, PMO, problems, process improvement, project management, retrospective, ROI, structure, templates | Leave a comment

Planning for a productive retrospective – 4 steps to better learning

We’ve all been there before – a project that hasn’t gone so well: over budget, late, not meeting everyone’s expectations (project death marches springs to mind).  And of course there are those projects which never actually finish – they simply no longer have anyone working on them.

The executives and senior management now want to forget, or worse still, want some heads to roll.

At the end of the project, the project manager or director (or some enlightened sponsor) may call a Retrospective (or Project Review, Hotwash, Post Implementation Review, etc) to get to the cause of what happened.

To maximise the value of this type of activity to the company, you need to collect both lessons learnt and data (to support the lessons).  It also helps protect you when the political ramifications start.  

Step 1 – Collect lessons early and often

If you’ve already started your project, or even getting close to finishing, start collecting lessons now!

Look through:

  • minutes of meeting and records of discussion
  • progress reports
  • project presentations
  • customer feedback
  • project emails – particularly those involving decisions made
  • audit reports

What commentary or narrative from the sponsor or project manager can you see?  What customer responses to decisions stand out?

Even the most poorly documented projects have some material upon which to extract lessons of what worked and what didn’t.  You just need to look for decisions and changes in the running of the project (or even if there were no changes despite them being needed).

This might seem like a lot of work and indeed most staff simply turn up to Retrospectives with minimal preparation and view it as a talk-fest to provide their opinions, rather than a serious analysis opportunity. In the absence of hard data and decision points, opinions often count only as loud as the person making them.

Step 2 – Ask reflective questions

Ask a reflective question at the end of each project standup/meeting – “what could we have done differently?”

The answers to these questions often make great sources of potential project and organizational improvements.  It is often difficult to separate egos from answers, however with focus on project and outcomes, the negative effects can be reduced.

Just like any continual improvement, record them in a central location such as a wiki, sharepoint or cloud collaboration tool. Don’t mix them up with other organization improvements or the effort may be divorced from the project and will lose any momentum or goodwill built up. Revisit and report occasionally to the project team to ensure the process does not go stale.

Step 3 Collect data

To support the lessons being collected in step 1 and step 2, start collecting data as early as you can – determine the measures that are available (or can be readily computed) and collect these throughout the project.

In many projects, basic measures are recorded and monitored (schedule, milestone, cost, earned value) but are not considered when thinking through lessons.  This is missing a potential wealth of material because by looking at decisions as they occurred during a project we can determine potential cause and effects (this is often rough and ready but is good enough to support lessons).

This may sound burdensome however the metrics are collected anyway and may require simple markups to match decision points to impacts on the project data.

Step 4 Communicate, communicate, communicate

Failing projects can bring out the worst in people – managers, team members, sponsors and customers alike.  All of whom are burnt out and over the project.  Most of all they don’t want to be blamed for the failure.  It’s critical for the sponsor and managers to step up and sustain an environment that enables staff to call out problems to get them fixed.  Learned helplessness is a corrosive behavior that can destroy a company.  Yet it happens in many companies by default simply because no one stopped it nor took action to prevent it.

By communicating at each and every opportunity, sponsors, managers and team members can build an expectation that problems called out will be addressed and not simply a blame game.  At every meeting and in every presentation and report, make this behavior front and center.  Each decision can be made with a fuller picture of the project and potential abiguities reduced.

In doing so, the politics of a Retrospective can be reduced and some real value can result.

In the next post, some obstacles and why equal time for positives isn’t a cliche.

Posted in alignment, appraisals, executive, improvement, manager, metrics, organization change, people, problems, process improvement, project management, quality, retrospective, strategy | Leave a comment

Make your PMO more relevant

Now that the initial PMO wave of enthusiasm has waned, it’s time to drive value through your PMO and make your team more relevant to the organisation.

Take some pragmatic steps:

  1. Identify specific gaps per project (or subproject) in your current portfolio
  2. Who is not delivering? Why are they failing? Insufficient resources? Underestimated effort, duration, scope or complexity?
  3. Provide staff to the project teams to assist in helping projects to fill the gaps – and not just fault find.

In all likelihood the already know the gaps but can’t prioritize sufficiently to address them. Or they may simply not view them with any importance – in which case you can give specific advice on what it will mean to not fill the gaps:

DON’T say: “If you don’t fill this gap, you will fail the next audit/review

They’re unlikely to care and are probably more interested in surviving to the next milestone and keeping fingers crossed they won’t be cancelled.

DO say: “We can help tighten the scope and remove unnecessary overlap with project Y”

They’ll jump at this sort of assistance.  Practical, timely, and visible.

Try to sell them on:

  1. Reduce cost
  2. Improve scope delivery on time
  3. Improve quality of what is delivered

Which of these are important to your team?  All of them?  Then which is the MOST important?  Then target your activities and suggestions based on that.

If you are just a glorified post box and just summarise what other people give you, you may not be around for long…

ACTION

Tomorrow, ask one team member from each project what is their most significant problems and what you can do to assist.

Posted in alignment, attitude, audits, checklist, Effectiveness & Efficiency, executive, improvement, leadership, PMO, problems, process improvement, productivity, project management | Tagged , , , , , , , , , , , , , , | 1 Comment