Search This Blog

29 September 2005

Quality Plans

Project Planning is a fairly complex and comprehensive activity.

A project plan is "A formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among stakeholders, and document approved scope, cost, and schedule baselines. A project plan may be summary or detailed." (PMI)A quality plan should show

  • What specific things will be done,
  • Who will do them,
  • When or at what milestones or process points they will be done
  • What are the relevant quality standards, and finally
  • Why this particular quality plan is in place (for context for the users of the plan)

Stakeholder analysis is a critically important task. According to Prosci ensuring stakeholder buy in is one of the top success criteria for projects.

Also knowing what will be done by whom (i.e. in the project plan) clears much uncertainty about the activities that will be done by the project in both the project tam and in the wider audience of stakeholders, customers and suppliers.

Planning takes a more methodical approach to solving problems, and enables the problem solver (i.e. project manager or team) to develop priority tasks, milestones etc as checkpoints along the way to the project’s success.

Steven Covey says that checklists are a fairly unsophisticated method of managing work. Covey puts forward the important/urgent-Quadrant 2 model as a better way to manage time and activities. He also suggests orienting work activities to relationship and outcomes rather than the detailed tasks.

Having thought further I can add some more opinions on what should be in the plan:

  • The plan should be focused at things that matter (you have to manage the project overhead and focus on where the most benefit can be found)
  • The plan should have specific start and end dates for activities
  • The success criteria or quality standards should be specific and measurable
  • Quality processes should have owners assigned to them

Quality plans in particular might be thought of as unnecessary overhead; after all they are often referring to things that are already in the project plan or the project process. Articulating the benefits of a quality plan can assist in ensuring that quality is given the right priority in the project.

Often those benefits are the same as normal project planning – the knowing the who, how, when etc to improve accountability and reduce uncertainty.

28 September 2005

Change this Tom Peters

The Professional Services Firm (PSF) is Everything. And the future of PSFs is lovemarks.

Global Competency Standards for Project Managers

A paper has been published looking and standardising performance criteria for Project Managers. Standard performance criteria should provide a bseline for measuring the quality of a project manager's work, which in turn should reflect the quality of project outcomes.

The purpose of the Global Performance Based Standards for Project Management Personnel initiative is to develop an agreed competency standards framework that can be used by businesses, academic institutions, professional associations, and government standards and qualifications bodies globally. This framework will form the basis for review, development, and recognition of local standards and will thereby provide a sound basis for mutual recognition and transferability of project management qualifications.

The public review for the GPBSPMP Global Level 1 and 2 is now underway

Another clue in the search ofr quality tools for PMs.

Found: via Max Wideman

26 September 2005

Designing for outcomes

Steven Covey wrote about designing for outcomes in ‘7 Habits of highly successful people’

The idea is that we design for the outcome we want and we end up working towards the outcome. If we design for abstract concepts they are harder to achieve. If we design for a process the process may work, but it might not deliver the results we want to see. Designing for outcomes can also reduce the scope of the problem and can also help remove the problem of specifying solutions when working on the design.

Spending more time on the design early will ultimately save time and cost.

In fact designing for outcomes is also one of the key tenets of the EFQM excellence model, a European quality framework competing against ISO standards. See more about EFQM here

Designing for outcomes seems so self evident that it seems odd to single it out, but many people design their specifications without clearly articulated outcomes in mind. Again, referencing Covey – if designs are oriented towards the outcome, the work will be oriented towards the outcome. This can help a project team keep focussed on what is important, and to prioritise work appropriately.

Many software projects are working on poorly defined problems, so the outcome is not known. Further, many other R&D projects are not trying to solve a specific problem, but just to explore generally. This doesn’t just apply to science, but to any innovation type development. Examples include google-earth and wikipedia –software applications that came before the ability to commercialise the product.

In most projects aligning design with outcomes is appropriate and very useful.

Since beginning this subject I have re-oriented by project (and day to day) planning towards the production of physical deliverables. And I usually start with mocking up a draft of what the document will look like before I get into the details.

(And I just saw a preview of the new Microsoft Office suite where in looks like the design for outcomes principle has become the foundation of the user interface.) Problems that people can encounter when designing for outcomes is designing work for the wrong outcomes. It’s important that the specifications address the (business) problem at hand, rather than addressing perceived or ancillary problems.

I hear a mantra from a manager years ago whenever I think about this topic; “Specifications talk about the need, not the solution.” Sometimes it takes skill to separate the two.

More comments on the SDLC

There are several popular software development methods, the most popular being the waterfall model. Agile and Rapid methodologies are the two main contenders at the moment to usurp waterfall development.

Whatever model is used the same stages are passed through in the same order – plan, design, develop, test and implement (or implement and test in some instances.)

Having a process that controls the development model is a good way to reduce risk and improve quality. Essentially the software development lifecycle is using a development process, and using a process is a quality management and quality planning exercise.

Project management adds overhead to projects that reduce risk. The SDLC does the same thing. In some instances the process followed may be too high overhead for the risk profile of the project.

This weakness presents an opportunity; part of the project planning activities should be around choosing the appropriate development process (or hybrids of models.)

New SDLC models are proposed regularly and being an early adopter can present risks to untried processes. Hence the waterfall method is still the preferred model. Scaling and varying processes should be undertaken to ensure that the appropriate risk/overhead balance is achieved.

25 September 2005

EFQM Excellence Model

The EFQM Excellence Model was introduced at the beginning of 1992 as the framework for assessing organisations for the European Quality Award. It is now the most widely used organisational framework in Europe and it has become the basis for the majority of national and regional Quality Awards.

The premise behind EFQM is that:
Excellent results with respect to Performance, Customers, People and Society
are achieved through Leadership driving Policy and Strategy, that is delivered
through People, Partnerships and Resources, and Processes.

The Model's 9 boxes represent the criteria against which to assess an organisation's progress towards Excellence. Each of the nine criteria has a definition, which explains the high level meaning of that criterion.

The framework defines excellence long the flowing measures:
  • Results Orientation - Excellence is achieving results that delight all the organisation's stakeholders.
  • Customer Focus - creating sustainable customer value.
  • Leadership and Constancy of Purpose - visionary and inspirational leadership, coupled with constancy of purpose.
  • Management by Processes and Facts - managing the organisation through a set of interdependent and interelated systems, processes and facts.
  • People Development and Involvement - maximising the contribution of employees through their development and involvement.
  • Continuous Learning, Innovation and Improvement - challenging the status quo and effecting change by utilising learning to create innovation and improvement opportunities.
  • Partnership Development - developing and maintaining value-adding partnerships.
  • Corporate Social Responsibility - exceeding the minimum regulatory framework in which the organisation operates and to strive to understand and respond to the expectations of their stakeholders in society

This framework seems to me to be an improvement on the quality frameworks I have looked at to date with their emphasis very strongly on process. This model includes a focus on process but also includes consideration of people, something that aligns with much academic work I have read into key success indicators for businesses.

Deming's Continuous Improvement Cycle

Plan: Design or revise business process components to improve results
Do: Implement the plan and measure its performance
Check: Assess the measurements and report the results to decision makers
Act: Decide on changes needed to improve the process
Picture from wikipedia

23 September 2005

Earned value management

Earned value management is a project management technique for estimating how a project is doing in terms of its budget and schedule.

Earned value compares the work finished so far with the estimates made in the beginning of the project. This gives a measure of how far the project is from completion. By extrapolating from the amount of work already put into the project, the project manager can get an estimate on how much resources the project will have used at completion.”

Earned Value can be used as a quality tool and a value management tool as well as a cost management tool.

See these other Earned Value resources:

Value Management

Value Management is:-
  • Process that establishes the most reliable performance which a product or process must do to make it work and sell at the least possible cost -
  • The analysis of products and processes to see where the greatest costs are being incurred and where the greatest value is added. This can lead to cost savings and better value for money to the customer -
  • Value Management has evolved out of previous methods based on the concept of value and functional approach -

Last night Eric Bishop presented a discussion on Value Management as a quality system. Some comments Eric made that I thought worthy of writing down include:

  • Value comes from relationships: If you don’t manage the relationships you won’t get value
  • Lifecycle costing is an excellent way to check if clients are getting value from functions you are delivering
  • Value is achieved through a thorough understanding of requirements, and requirements are about delivering a client capability, not a thing. My interpretation of this is don’t ask, “What do you want?” – ask “What do you want to achieve?”
  • Spend a lot of time listening to, and getting into the minds of the client.
  • Make sure you are speaking with the right stakeholders
  • Build flexibility into design – so that future, unknown requirements can be addressed more easily
  • Your ability to influence value declines over the life of the project (like all other types of influence.)
  • Give your team value and get value back (His management style)
  • Continue to assess cost/benefits of features and functions throughout the project

Value Management is one of the lesser used quality techniques in project management (along with lifecycle costing. See this study by Besner and Hobbs at the PMI website.

Related topic: Value Engineering:

  • Value Engineering is a systematic method to improve the "Value" of goods and services by using an examination of FUNCTION. Value, as defined, is the ratio of Function to Cost. Value can therefore be increased by either improving the Function or reducing the cost. It is a primary tenet of Value Engineering that quality not be reduced as a consequence of pursuing Value improvements - wikipedia

22 September 2005

Hammering Hammer - Are processes the answer to quality?

ISO9000 is about system or process oriented quality systems and is used around the world in all sorts of industries and often in project environments, but is it the right model? ISO has it’s shortcomings. Some are listed on the ISO9000 entry on wikipedia.

Hammering Hammer is an article challenges the process orientation of modern business with the proposition that while processes are reliable, repeatable things, the real world is full of unique and individual situations, many of them unexpected and unable to be planned for.

Where does this leave quality assurance on projects? Projects address unique situations with unique approaches, however the PMBOK and general PM theory takes a very process oriented view of managing projects. Are projects able to be quality assured the same way as daily operations?

The Hammer article also challenges the Theory X management paradigm that Hammer (and other process gurus) tends to lean towards in a search for certainty and simplicity in the people management function. Again that raises an interesting challenge: how to quality assure people management in an unstructured or undefined environment (for example in defining software specification.)
My question remians unanswerred for the moment.

refernce: Hammering Hammer, Rogue Project Leader Magazine and as usual wikipedia.

21 September 2005

Service quality and projects

Projects are services for (usually) businesses so now that I have decided that I like the RATER model with certain constraints, how can it help me in project management?

One of the things that keeps coming up in discussions about projects’ success is the need to be measuring the right things. An example is the project where the sponsor made a million dollars, but the target was $1.5million. Is it a success or a failure? It all depends on what the sponsor was really trying to achieve.

Design Management Principles

For me, in the work that I am usually involved in, design management usually means ensuring that documents are produced at various stages saying what is to be done (requirements specs, architectural plans, solution designs, project plans) and what has been done (Test results, updated Requirements Traceability Matrices.)

As far as managing requirements (from Strategic Needs, and oriented towards outcomes) through to delivery the RTM is the end-to-end tracking tool. However, it relies upon the creation of the other documents to track requirements through the process.

“Specifications talk about the need, not the solution.”

Another important thing to consider when looking at design principles is ensuring that all appropriate voices are heard through the proper identification of, and discussions with stakeholders. If stakeholders aren’t consulted about their needs, their needs are unlikely to be effectively addressed by and solution design. Another aspect to design management is change management. Change management is a formal process of introducing change into the scope of the project. Change management against design items is a subset of the change management processes described in the Scope Management topic.

Writing up designs gives stakeholders a chance to read and agree to them, or to highlight any gaps that they see. This usually requirements more than a diagram or document, and in my experience facilitated communication works best (ie a presentation or workshop about what is actually being described in the document.)

The RTM also provides a simple and powerful tool to track what needs/requirements are being addressed at each stage of the development cycle. The use of an RTM works best when there is a clear development process that all project participants are aware of.

I can’t think of any weaknesses in relation to having a design principles and a good control process in place. Again it seems like a very natural thing to want to do.

I suppose that the key thing to ensure that design management principles are effective is to ensure everyone knows what they are and why they are there, including the people controlling changes. Changes aren’t bad, and in many projects there has to be changes to ensure the client gets a satisfactory result.

Thinking about this topic presents me with an opportunity in my work practices. I want to ensure that in future I communicate the design principles and process that we will use to the stakeholders, and not assume that they know what we are doing and why. The threat in this area comes from people who do not know why certain processes or practices are being followed; and again the answer is communicating.

20 September 2005

SERVQUAL and RATER Service Quality models

SERVQUAL or RATER is a service delivery quality framework. SERVQUAL was developed in the mid eighties by Zeithaml, Parasuraman & Berry.

SERVQUAL was originally measured on 10 aspects of service quality: reliability, responsiveness, competence, access, courtesy, communication, credibility, security, understanding or knowing the customer and tangibles. It measures the gap between customer expectations and experience.

By the early nineties the authors had refined the model to the handy acronym RATER

  • Reliability
  • Assurance
  • Tangibles
  • Empathy, and
  • Responsiveness

SERVQUAL has its detractors and is considered overly complex, subjective and statistically unreliable. The simplified RATER model however is a simple and useful model for qualitatively exploring and assessing customers' service experiences and has been used widely by service delivery organisations.

== Criticisms ==
Francis Buttle critiques Servqual in the article “SERVQUAL; review, critique, research agenda and comes up with these three key criticisms: Perception and expectation are very subjective, and thus not good measures, that there isn’t necessarily a direct relationship between service and quality, and the measures in the model are not necessarily the right things to be measuring.

== References ==
Delivering Quality Service; Balancing Customer Perceptions and Expectations, Free Press, 1990.
Francis Buttle, SERVQUAL; review, critique, research agenda European Journal of Marketing, MCB Press, Issue 30.1 pp 8-31

Managing Scope

In project management, scope is the sum total of all projects products and their features. Scope can also mean the totality of work to be done by the project team. Scope sets the boundaries of what work is going to be done by the project team, and what the boundaries of the problem that is being addressed.

A project such as the current project that I am working on is only addressing some of the problems with the exiting business process. Others are uncovered as we investigate the current processes and gradually the scope changes. The management aspect of scope management is called ‘change management’ where changes to the scope are assessed, usually in terms of the benefit to be achieved against the impact to the project’s planned budget and schedule.

Often in business improvement projects (i.e. ones that usually include software development as a key part of the solution) the business client/sponsor does not exactly know the scope of the problem and it gets revealed gradually.

More time spent planning can address the above problem, matched with a good change management system that allows for justified changes. When sponsors and project managers take a too hardhearted approach to change management a tightly managed scope can result is a product that doesn’t deliver a user/customer a satisfying result.

Small things that affect a system’s useability are not considered valuable to a sponsor but are frequently very important to users and customer.

An example I am aware of is a website where customers can change their credit card details according to a bunch of business rules. When scoping the project a customer initiated lowering of a credit card limit was initially forgotten. The cost of building in the changes to the schedule was considered too high and so the website went live without that function. The result is that some of the benefits of reducing customer calls were not achieve, and customers who try to initiate a credit reduction are frustrated as their expectations of the company (an comprehensive and easy to user website) are undermined.

12 September 2005

W Edwards Deming

W Edwards Deming (pictured c1970) is The Quality Guru. Deming is most famous for bringing his flavour of scientific management to Japan after world war 2 and contributing to the wave of quality through systems thinkers popular in the mid to late 20th century.

If you are looking at quality in the context of projects Deming is a good place to start. Read about him and his work to understand key concepts like the challenge in defining what quality is, and how systems can bring quality to organisations.

A big part of what he introduced into Japan was the concept of managing Quality into processes rather than managing defects out, through inspection. He also introduced me to the idea of continuous improvement as a way of managing business operations.

There is a good Wikipedia entry on him here.

Projects tend to have a fairly mechanistic approach to working and the people on them usually think like engineers to Deming's approach seems a likely one to work in the project context.

9 September 2005

Project Planning

As I (think I) have mentioned below I am working on an assignment responding to a tender. The assignment's idea is that the planning process in the tender response makes our project team walk through the project management planning activities of:
  • Developing a WBS, with dependencies, activity descriptions, etc
  • Estimating the time and effort required through scheduling
  • Estimating the cost, and determining a price to go to the tender with.

As part of the excesses have put the below process together as a framework to manage the assignment to. It was made in response to the idea that we should start with pricing ourselves according to the market, rather than taking time to understanding our costs first.

In my mind this is the logical sequence in the planning phase. Of course there is a lot more detail and even other activities that can be considered, but given the assignment scope this is a good breakdown of what we need to do.

7 September 2005

Allocating Contingency

The last topic for today: Allocation of contingency.

For a while now I have worked on projects where contingency is not allocated at task level, just at the project level. The project leaders and team members have tried to estimate accurately what the effort required will be. The project leader will usually accept reasonable reasons for lateness including lack of experience and incorrect estimates.

The overrun is then taken from the overall project contingency (which should have been factored to include the teamÂ’s experience and any other risk issues.) This strikes me as better than everyone adding contingency at task level, then more contingency at a work-stream level, then more again at the project level.

Previously we had a discussion of who pays for changes - and us IT workers tended to charge all changes to the business unit that requests them, while construction people tend to manage it according to the scale of the change - often taking the change costs out of the contingency.

Other views on contingency management:

Overcoming Microsoft Project - Resource Allocation

Microsoft Project always sucks when you want to look at your team's resource loading over the project. The histogram in MS Project doesn't give a good, scaled view of the team over time.

In a lecture I was at last night Michael showed a simpl and obvious tip; he simply cut and pasted data from project's Resource Usage screen to excel and then simply created a histogram.
An obvious solution, but one I had never thought of.

Development methods and Estimating

And yet more on Resource Allocation and Management.

As mentioned below many estimates are made from asking experts and specialists or past experience. In class we had a discussion on the impact of using historical experiences for estimating effort on IT waterfall projects, which are heavy on planning and estimating. The issue was raised that if our programmer estimates 5 days to complete a piece of work to specifications and he completes in 2 days the extra three days are not given back to the project, but used to improve the quality of the work, often beyond the requirements.

Rapid Application Development was discussed as a concept that can alleviate this issue to a degree. Several iterations of the solution are developed until the appropriate time, cost and quality balance is achieved. I think Agile methods are probably a better model for addressing this soaking up of excess time, as the developer and businessperson are more closely aligned in their view of what needs to be done.

There is probably an opportunity for someone to do some research in this space. Or if some has been done for someone to tell em about it :)

I'm still loving wikipedia

Learning from Timesheets

Still on last night's lecture; A suggestion was made that timesheet activities should be mapped against WBS activities so that you (or the organization managing the timesheet) can learn to estimate better from the information.

The idea is that if a timesheet is mapped to an activity, say developing a Training Plan, then over time an accurate picture is developed about how long a training plan should take.

Of course most timesheets are not recorded at that level, rather they map to a project or cost centre's allocation to the project, which works is a particular person is allocated to the one task of developing the training plan. And that's rarely the case.

So - a thought, and an opportunity for improvement.

I just added this idea to wikipedia's timesheet article.

Primary and Secondary Resources

Last night's PM Techniques lecture was called Resource Allocation and Management.

A concept was introduced that I had never heard of: Primary and Secondary Resources. Previous to last night I had thought of these issues in terms of either:

  • Research: Primary resources being artifacts like historical objects or surveys, secondary being interpretation.
  • Economics: Primary resources being raw materials like iron ore, and secondary being processed like steel rods.

The concept in project management is:

  • Primary resources are resources that are available immediately, and
  • Secondary resources and resources that will need to be procured.

It's impact is in resource leveling and scheduling; you manage your costs and cash flow better without peaks of labour use, as well as the many other benefits you get out of using your regular team.

These pictures came from The Professional Council for Religious Education's website

Project Management Maturity

I stumbled onto another great article at Max Wideman's site (if you are fascinated by project management that is.)

In 2004 PWC did a survey on companies' project management maturity and their project effectiveness. The results are here in a document called Boosting Performance through Programme and Project Mangement.

I am yet to read the report but will do so in the next few days and update this post.