27 October 2005

Kano and quality requirements

Project requirements specifications identify what the project wants to change. An understanding of the business processes and the business data with their related problems and opportunities, as well and environmental constraints and guides is required to fully understand requirements.

Requirements can also be categorised into classes along the lines of the Kano model:
  • Threshold / Basic attributes
  • One-dimensional attributes (Performance/Linear)
  • Attractive attributes (Exciters/Delighters)

All threshold requirements must be met, one-dimensional requirements should be weighed on cost-benefit assessments while attractive attributes should be included wherever possible, but are the ones usually washed out by time and cost considerations.

16 October 2005

Strategic Needs Analysis

Strategic Needs Analysis (SNA) is a pre-design activity that usually uses a workshop setting to focus stakeholder involvement in proposing and identifying a range of strategic options for the proposed project.

SNA is a tool that can assist a project team from avoiding the problems associated with assuming they know the client’s problems. There is an assumption with SNA that the client, or the workshop participants know the problem and the business environment well. There is a challenge in relation to SNA; many business representatives to SNA meetings do not know the problem well. The project must ensure that the issues are well analysed to ensure that the appropriate needs are identified. The SNA participants should avoid designing solutions as much as possible, although naturally knowing the relevant constraints become a part of articulating the business needs. SNA statements are the foundation of the quality and success measures for the project.

The benefits that projects bring should be aligned with a business/organisation’s strategic needs. Ensuring that a project checks it’s intentions against the strategic needs of the sponsor or organisation gives the project a top line set of objectives that all subsequent work can be checked back against.

I think this, along with Sponsor buy in and effective people change management are the most important quality activities that a project can run. I like to use the Requirements Traceability Matrix to track requirements right from the SNA session to ensure that all elements of specifications, design and delivery align with the businesses’ needs.

Not all sponsors and organizations have a clear strategy, but still need to run projects to meet market demands. For example a banking business may be in the middle of re-assessing it’s plans for the future – maybe even exiting the industry, but still needs to run compliance projects to enable them to stay in business for the short term. This suggests that strategy is multi levelled and the project’s place in the organisation may align to the strategic needs of a business unit rather than the organisation as a whole. I see this in practice with capital review boards, which address projects at different financial expenditure levels.

This is a great and reasonably simple exercise that should be run at the beginning of each project. It can also be used to develop relationships with all the main stakeholders. It can also be used to check whether the project should even be run. And to determine whether you as a project manager want to run it. The strategic needs can also be sued to baseline the project’s objectives and to ensure that the project activities stay aligned to its purpose.

If a project is not aligned with the business’ strategy it will likely fail regardless of how well it is run as it can end up having no ownership by most stakeholders. I briefly worked on a project where the objectives were not aligned to the business strategy and over the first few months it became very obvious that none of the general managers, except the sponsor GM, wanted the project. And the project wouldn’t be killed. The PM delivered the project above all success criteria (i.e. early, cheaper, higher quality) and the project was still a failure, as the business did not take up the new service.

Source: Stakeholder Management during Project Inception: Strategic Needs Analysis by Jim Smith, and Peter E. D. Love, Journal of Architectural Engineering, Vol. 10, No. 1, March 2004, pp. 22-33)

Stakeholder Management and 'Different Approaches'

In a presentation about Melbourne Council’s park and organ redevelopment projects the key message was about stakeholder engagement and management, which was ironic because when questioned it appeared that the council’s policy was one of manage the stakeholders by keeping them out of the way of the project and the ‘real work.’

This was fascinating for me as all the stakeholder related literature and articles, and all the previous discussions and experiences I have had all say the same thing:

It's critically important to listen to the stakeholders.

I investigated this issue further with people who have worked on several state and federal government projects and the message consistently came back: That is indeed the way the government works because the stakeholders in politics are managed differently. In politics the stakeholders are apparently more narrowly, and pragmatically, defined as groups that can influence election results, rather than simply having an interest in the project and it’s outcomes.

Fair enough. Not all projects are the same and you need to do a proper analysis on who our stakeholders are and why. This seems to have been done. In most projects though, stakeholders range a bit wider.

Stakeholders are usually anyone who has an interest in the project and can exept influence on its performce and success. Some definitions have excluded project team members, suppliers or customers, but as the roles and relationships between projects, organisations and the communities become more complex it becomes increasingly difficult to exclude anyone from being a stakeholder once they express a stake in a project’s existence or outcomes.

Knowing who your stakeholders are is very important as it enables you to go to them and address their needs, wants and any other concerns they have (eg constraints, guidelines etc.)There are many studies and articles that show a close relationship between stakeholder management and project success. Much of what projects do is implement change, and usually it is people that have to change – the stakeholders. So knowing who they are is an obvious starting point.

The next stage is to ensure they have the opportunity to participate in decisions about their future, a technique that will empower them to adapt to the change. Other change management techniques are also required for effective people change management, but that’s another topic.

The biggest weakness in stakeholder management that I can think of is not addressing stakeholder needs and wants. Kano’s quality framework (needs, linear improvements and excitement factors) suggest that if you are not talking to stakeholders you can’t know what their excitement factors are, and so your results will only be perceived as sufficient rather than excellent. (We all love Tom Peters! and want to be excellent!)

A challenge in effective stakeholder management is knowing all the stakeholders. A CEO of an American corporation (I can’t remember which) Suggests that you simply ask everyone who else should be included on the list. This is a system that seems a simple and practical way to identify all your stakeholders in almost all circumstances. Wrapping that up with a formal document listing can assist this.

It can be easy to think that once your stakeholder list is done the stakeholders are all identified, however as the project progresses more stakeholders can come into existence either through knowledge about the project travelling, or the areas the project gets involved in changing. I worked on a project a few years ago where we decided to outsource what we originally planned to build ourselves. The local procurement office then became a stakeholder, where for the months prior they had not been.

12 October 2005

PDMs - Precedence Diagram Method

The Precedence Diagramming Method (PDM) was developed in the early 1960s by H.B. Zachry in cooperation with IBM.

It has largely replaced Arrow on Node diagramming. PDMs represent activities as boxes that are assigned properties of the activities they represent.

See here for a good Article on benefits of PDMs. PDMs are popular and useful because they can:
  • Help find the critical path
  • Help define the amount of time required
  • You can use them to crash projects
  • You can use them to flatten resources
  • Define dependencies/precedence
  • Identify lead and lag times
The fundamentals of a PDM element are represented in the below diagram:
  • Precedents or dependencies
  • Earliest start
  • Estimated duration
  • Earliest finish
  • A description of the activity
  • Latest start
  • Float time
  • Latest finish

In practical terms revisiting the basics has enabled me to be more effective in plotting schedules into Project. I used to tackle tasks/activities in a sloppy fashion, but since walking through the basics I have had to put together two project schedules, and I took a more disciplined approach to each and have a much more satisfactory result, especially when the changes start rolling in.
An article called "Four scheduling exerts" by Richard Korman with Stephen H. Daniels at the PMI website discusses how the PDM is often biased and what should be done about it. The essence of their answer: make sure people are properly trained and experienced. And the American Society for the Advancement of Project Management also has an article "Let's scrap the PDM" which suggests node and arrow plans are better.

6 October 2005

Quality Management and Quality Assurance

Quality Management is the processes and systems in put place to ensure that a project or business activity is geared towards a quality result. I think it was Deming who came up with the phrase/concept of ‘managing quality in.’

Quality assurance is the process of managing defects out of the production process and comes from the work of Schewart and his statistical control tools.

Topics that come from juxtaposing Quality Assurance and management with Project Management included their similarities in purpose and approach. Both are about managing risk and quality during change, both rely on a systems approach to get things done and both follow the plan, do, check, act paradigm.

Quality management is a proactive approach to designing quality into systems and outcomes. To effect this an understanding of what quality is defined as is required.

Quality Assurance is still an integral part of driving quality into outcomes and is most apparent in IT projects at the testing phase. Manufacturing and service businesses have often used sampling a smaller number from the total to test quality (eg mystery shoppers, testing 1/10,000 glass bottles, etc) however IT projects tend to test everything they can think of in the test phase of the project. Usually every function is tested positively and negatively, along with end-to-end processes, interfaces between other systems and users etc.

I think that sometimes the quality management aspect of waterfall software projects (i.e. the total-ness of testing) is overkill in many projects. Agile and Rapid methodologies offer a prototype and refine type model which can save time and money and still get good results with customers. The challenge is for large corporations to be able to integrate these methods into their business processes without compromising perceptions and the reality of quality outcomes.

After researching a few definitions of quality I have come up with a new way of defining quality for my projects. I discussed a few ways quality can be defined with colleagues and friends and most project managers and BA's came up with ‘fitness for use’ as the definitive measure of quality. In a meeting with technical staff at work they came up with ‘all requirements are met.’ I then asked a client of a team who will use our project’s outputs and he said something to the meaning of ‘my staff have to like using the system.’

This led me to look at Kano’s quality model for requirements.

We have often broken business requirements into similar categories but now the whole team is looking at the experience the users will have with our project’s output as one of our success measures and the delivery of highly valued "Delighters" has become core to our viewof what we shulod be doing.

I think this is a great approach to quality.