Quality Management (HIGH LEVEL Overview)

As the first step we need to clarify what quality is.

In a sense quality relates to all 3 parts of the triple constraint and is equally important to them. If a project is not performed on time, according to the specifications and within budget it is not considered successful. Project quality is about a project performing faster (time), cheaper (cost) and better (scope) than it is currently performing.

A more formal quality definition is in PMI's PMBOK (Chapter 8):

Project Quality Management processes include all the activities of the performing organization that determine quality policies, objectives and responsibilities so that the project will satisfy the needs for which it was undertaken.

Note that quality might be defined differently by various quality leaders and organizations.

There are several formal quality systems

• Malcolm Baldrige National Quality
• ISO 9000:2000
• SEI's Capability Maturity Model
• Six Sigma
• Lean Sigma
• Deming Prize

One important note: Quality has a price! Make sure at the beginning of a project that all stakeholders have the same understanding of what quality they want to achieve. See also this link for more info on cost of quality and cost of non-conformance

Project Quality Management has 3 process steps

1. Quality Planning
2. Quality Assurance
3. Quality Control

During these processes different steps need to be looked at and a number of different tools can be used

1. Quality Planning
    What needs to happen during this step?

• Stakeholders need to be identified and prioritized
• Project Quality standards/expectations need to be identified and prioritized

      A quality standard should be
               S   pecific
               M easurable
               A  ttainable
               R  ealistic
               T   imed

Example: Quality Standard : Every hard disk of notebook xyz will work w/o any maintenance for 24 months or 15,000 hours

2. Quality Assurance
     What is quality assurance? This activity describes who, what , when, where and how a quality standard
     will be measured.
                 
     These activites must be measurable, relevant (meaning related to the quality standard), integrated in the
     quality system and someone needs to be responsible to ensure the activities occur.
     Some tools which can be used during this step: Gap Analysis, Flow Charts, SWOT Analysis

3. Quality Control
    from PMBOK: ".. monitoring specific project results to determine whether they comply with relevant
    quality standards and identifying ways to eliminate causes of unsatisfactory results"

     To put this very simple: Is the customer satisfied with the quality? This is related to the requirements
     and quality standards that were developed in step 1.
     Some tools which can be used during this step: PDCA Cycle (plan, do, check, act) from Six Sigma
     Histograms, Pareto Charts, Flow Charts, Cause-and-effect diagrams, scatter diagrams, run charts,
     control charts

Summary: Quality Management is a HUGE topic and this is obviously only a very first glance at some of these areas.

Here some links that might help to delve deeper in this topic
Six Sigma
ISO 9000
Wikipedia - Quality Management

Risk Management Overview

Please note that I'm providing a very short and high level risk management overview here. For a deeper coverage on this topic see also PMBOK Chapter 11 (Fourth Edition). There is a ton of information on the web and it makes sense to check several sites to get a better overview.

Risk Management with regards to project management deals with project risk. A project risk is something that has a negative impact on at least one project objective. Note that typically Risk Management also includes opportunities. For this short overview though I'd like to focus on the more common understanding of project risk as described above.

Different people have different perceptions about risks. Some people want to avoid all risks and some  always assume the best and don’t see any risks. It is important to establish a common Risk Strategy at the beginning of the project to ensure a common understanding and proper use of Risk Management. The project manager should determine the priorities with the project sponsor and then update the team.

Some benefits of Risk Management are:

• minimizes issues and surprises
• decreases probability of issues occurring
• increases probability of project success

 In general we can distinguish between the following risk types:

 - Business risk - normal business risk. e.g. Business conditions changes during the project or scope, time, budget for your project is changed

- Insurable risk - This could be e.g. Tornado. The risk should be avoided or at least the impact be reduced (e.g. buy insurance)

- Known risk - e.g. not enough resources available at a particular time to achieve project objectives

- Unknown risk - these risks are always there and you will have to deal with it

To make Risk Management successfull the Project Manager as well as the Project Team has to understand, accept and use the risk management process.

Please note that the Risk management process needs to be applied during all project stages

Example:

- Business requirements are submitted

- Risk Management determines risks associated with these business requirements
- Project schedule is build
- Risk Management determines risks associated with the timeline, resources and effort Estimates

The Risk Management process contains the following 7 steps

1. Identify the risk (e.g. Expert interviews, brainstorming, questionnaires, etc.)
2. Analyze the risk (e.g. how likely is this risk?  High/Medium/Low)
3. Prioritize the risk (e.g. what is more important to you scope, time or budget?)
4. Find an appropriate response to the risk (e.g.

• Accept the risk – if the risk can’t be avoided, minimized or transfer you will have to deal with this risk
• Minimize the risk – this means reducing the probability of this risk to occur or at least minimize the impact when it occurs. It’s important to note that the risk cannot be completely eliminated.
• Transfer the risk – in this case we shift the risk to another party but we do not eliminate the risk
• Avoid the risk – in this case the risk is eliminated. This means you know about this risk and can plan to avoid it.

5. Execute the response to the risk
6. Evaluate how the execution worked (review risks regularly, e.g. review how the risk probability was impacted etc.)
7. Document the results (e.g. this will provide valuable info for your lessons learned records)

Here is an example of a Risk Management Plan

Column in Excel                                                                                    possible field values

Risk Status                                                                    open, closed

Last Review date

Risk Description

Probability of Risk                                                         High, Medium, Low

Risk Impact                                                                   High, Medium, Low – this is related to the

                                                                                     probability of the risk

Current status (compared to previous status)                  Better, Same, Worse

Risk Owner                                                                   Name of Risk Owner                                  Response                                                                       Accept, Avoid, Transfer, Minimize

Notes                                                                            Additional info’s regarding Response

Requirements Process for Business and IT related projects

Before we go back to the areas mentioned in the last post let's spend some time on the requirements process.
The requirements process is an extremely important part and hence we need to understand what needs to happen here before we go into the different project knowledge areas.

Some important notes about requirements

- Requirements need to be prioritized

  Before the project starts agree what document you want to use for the HIGH LEVEL requirements. It

  might be helpful to gather this info on a spreadsheet.

- The number of requirements needs to be controlled. If you have more requirements than you can  

   handle set a challenging but realistic requirements threshold.

   If you have a set timeline by your project sponsor keep in mind how much development time you have and

   what is most important to your project sponsor.

- Remove duplicate requirements as early as possible to ensure less confusion

   this needs to be done during the HIGH LEVEL requirements gathering in order to prevent confusion

- Ensure volume and performance requirements are clearly stated

  How many people, processes etc will use your solution? Clarify this as early as possible so that you provide

  the best possible design for the desired solution

  

- Set timelines for the requirements process and stick to it (e.g. set a requirements submission deadline)

   It's simply a good planning practice. Don't forget to add some slack.

     

- Keep the requirements document under version control

   This ensures that every stakeholder understands what is in and what is out of scope. Requires a thorough

   communication plan.

  

- Once the submission deadline has passed implement a change management process to handle

   additional requirements (new requirement submissions or changes to existing requirements)

   This ensures that the scope change fits within the time and budget expectations (if it is done

   properly)

- Ensure stakeholders have access to requirements

- Do you need any internationalization (translation) for your project? If yes, have all requirements  

   been  clearly documented?

   Ensure that you have test cases for all internationalization related functionality. This could be a translation or

   a different system behavior in another country, sub-region or region

- Ensure all Hardware, Software and communication interfaces have been clearly defined

  This is one of the Key points since the interfaces tend to cause the most issues.

- You should be able to create a use case / test case for every functionality that you develop or plan

   to use

Here some good articles on the requirements topic from Karl Wiegers

The Requirements Document should contain these area's

System Overview
1. Overview
     * Analysis
     * Assumptions, Risks, Dependencies
     * Estimated work, cost

2. Scope Requirements
     * end-to-end business flow
     * Workflow + System Diagrams
     * Impact Analysis, System contacts

3. Business Requirements

4. Functional Design

5. Data Conversion Requirements

System Design

1. Data Flow Diagram

2. Data Model

3. Integration requirements (e.g. includes Interfaces)

4. System Process (Input, Process, Output)

5. Error Handling

6. Security requirements

7. System scalability

8. Performance requirements

Test Plan (a.k.a. Quality Plan)
1. System Performance Requirements

2. Use Cases for Testing

3. Test Plan

4. Issue Handling

The next post will on November 21 and then we go into the different project knowledge areas.

Project Management - Basics for Business and IT related Projects

There are many books on Project Management and many theories what works and what doesn't work. But all this information does not guarantee you a successful project. When you consider the high project failure rates you can question how many projects are run with the necessary Project knowledge today. Here is an interesting article from Harvard Business Publishing concerning Project Management experience

In general it is a question of whom you or your management trusts to get the job done. If you're in a big company you might have to choose the consulting company that is on the approved vendor list of your organization. In many cases these will be big consulting firms that offer higher manpower and safety and also charge higher rates.
For a medium or small size company you might want to find the local consulting company that best suit your needs. These consulting companies won't offer the breadth of the big consulting companies but they are most likely niche specialists that might offer lower rates.

Whatever the answer is some key questions need to be answered before any IT related project can be successful

Some example questions:
          - Do you have resources with sufficient Project Management knowledge that can lead your project?
          - Do you have in-house IT resources that conduct the project or will you have to use external IT
             resources?
          - Did you specify and document your business requirements clearly?
          - Did you identify all the stakeholders of this project?
          - Do you have a clear picture of the Cost, Scope and Time priorities for this project?
          - Does your budget cover the necessary effort?
          - Are your business processes stable enough to justify the deployment or development of this project?
          - Do you have an idea about the expected Return on Investment (ROI)?
          - Do you need external resources on an ongoing basis to maintain the outcome of this project?
          - Do your users support the development of an IT solution?
          - Did you specifiy exactly what constitutes success for the Project?
          - Do you need deep industry knowledge to come up with the best solution or is it an added value to
             engage someone outside your industry to get new ideas?
          - Do you want to engage resources that are onsite or can you use remote resources?
          - What are your quality expectations for the Software deployment? (e.g. 99% availability etc.)

A Project should generally start with a project charter that clearly states the purpose, objective and scope of a project.  (see also this PMI link).

Once you know what you want to achieve (via the Project Charter) you will need to determine how you can get there. So the next step is to assemble the team that will execute the project. Depending on the size of your organization you might be able to pick your team members or you have to take the organizations that are on your approved vendor list.

You will have to gather requirements and document them unambiguously. This sounds simpler than it is. To get unambiguous requirements is a real challenge for any organization. You need to spend considerable time here with qualified resources that can question the purpose/benefit of your requirements. One key question to keep in mind is the Return on Investment. WHY do you do this? What do you expect to get out of this project? In one of the next posts we'll dive deeper into this section.

Once you have the unambiguous requirements you need to estimate how much effort it will take to implement them. This means you have to come up with a time and cost estimate. There are several methods on how to provide cost and effort estimates. You will also have risks related to the cost and effort estimates and you have to think about how you want to keep track of them.
One of the KEY TASKS during any project is how you plan to communicate to all your stakeholders.
This can make or break a project! All your stakeholders need to know what is going on. How do you plan to do that? What communication methods do your stakeholders prefer? email, phone, video conference, face-to-face? At that point you should think about a communication plan. The bigger the project the more important this becomes.

At this point you have a scope plan (what do you want to do), a schedule (effort estimate), a cost estimate (how expensive are the resources that you need, what non-labor resources do you need), a quality plan (what constitutes a successful project), a staffing plan (which resources and how many do you need to achieve what you want to do) and a communication plan (how do you plan to communicate with all stakeholders of your project)

In the next posts we go into the different project knowledge areas (Integration Management, Scope Management, Time Management, Cost Management, Quality Management, Human Resource Management,
Communications Management, Risk Management, Procurement Management) in more details and will provide some, hopefully useful, tips on how to master Business Management + IT projects for different organizations (Small, Medium, Large)