Scope Management using Kano Model

What is the Kano model about and why is it important?

One of the important areas for Project Managers to lay emphasis on is Scope Management. Typically this has two dimensions- product scope management and project scope management. While product scope management deals with features and functional requirements, project scope management is about the scope of work involved in terms of activities in a project. The challenge for a project manager is to finalize both scopes and deliver on time within budget, yet fulfilling quality objectives and keeping the customer happy. The Kano model is a model which helps a project manager and business analysts to focus on product scope and helps to utilize resources in a better way to keep the customer happy. The model was proposed by Noriaki Kano in 1984. Although it is originally a quality driven initiative, the use of this in fixed time, fixed price projects helps to manage the requirements scope well to satisfy the customer.

The premise for the model is that if one can differentiate and classify customer requirements based on how it can influence customer satisfaction, it gives an edge to the project team as they can prioritize and focus the work towards features which the customer regards as important.

Requirements classification using Kano Model

The Kano model classifies feature requirements into three quality categories: Expected, Normal and Exciting. (also referred sometimes as Must-be, One Dimensional and Attractive). Below table shows the definition of these classifications:



How to classify the requirements?

The requirement classification is done through interviews and questionnaires. The questionnaire proposed by Kano is widely used to classify requirements. Each question has a functional and a dysfunctional part which has to be answered by the customer. Below are examples:


Based on the answers, for each feature requirement, the classification is done based on the below look-up table:

Category ‘Reverse’ implies that the feature is not only required but the customer also expects the reverse. This means that the response is inconsistent and needs to be re-checked.The below diagram shows a visual representation of the Kano model:

Summarizing results from the Kano questionnaire

The results from the Kano questionnaire are summarized to classify the requirements as shown below:

The evaluation rule to determine which feature requirements need to be met first can be determined by the rule Expected>Normal>Exciting>Indifferent. First requirements which cause dissatisfaction have to be met first. An approach that can help could be: meet all expected requirements; show competence with regard to normal requirements and make the difference from the competition with few exciting requirements - Of course, keeping time and budget constraints in mind.

Conclusion

The Kano model has been used in wide range of industries for product design. It has been applied also to the information technology world for solution design. A Standish Group research has brought out facts that on an average only 20% of software features are used always or often and 45% of the features are never used. Obtaining customer satisfaction by using the Kano model has potential gains to the vendor as well as the customer.

Effective Stakeholder Engagement

In any entrepreneurial activities bringing about changes you will have to deal with individuals or groups interested in the outcome or simply impacted by your project or program.

Depending on the breadth of your project or program, the list of stakeholders can encompass public government, media, public opinion influencers and corporate management.

Independently from the constituency you are referring to as a manager willing to ensure the highest probability of success to your initiatives you have to engage them.

Managers need to think of Stakeholder Engagement not only as a set of tasks to execute, but also as a way of achieving influence and positive outcomes through effective management of relationships.

In order to reach this virtuous balance, in designing your management strategy you have to identify all your stakeholders and analyze their profile in the context of the project or program you are operating.

The identification phase takes different shapes but usually it utilizes one or more of the following approach

1. Brainstorm with your team
2. Analyze the project brief or the program mandate to discover impacted people or groups
3. Utilize historical information from similar projects
4. Seek the advice of identified stakeholders to determine whether there are groups or subgroups you have overlooked

As well you will have to single out the domain of interest on the project for every stakeholder.
For example, some stakeholders will be concerned with how a program will affect their business processes while others will focus on the way a program will modify the reporting system.

The analysis of the interest areas for each group can be represented in a matrix - a Stakeholder Map. The Stakeholder Map in the following figure compares the various stakeholders against their interests in a project dealing with the implementation of a new reporting and finance package.



Once identified the interest areas you have to consider the stakeholder potential interest in the program/project outcomes as well as the power (influential or positional) of each stakeholder.

This evaluation is important since it will allow you to plan the effort you invest on each stakeholder and to develop a communication plan that is aligned to each stakeholder or stakeholder group's focus and concerns.

A common approach is to map the interest and influence of each stakeholder group on a quadrant of an Influence / Interest Map and structure an engagement strategy for each group as illustrated in the following picture.



Because of the evolving nature of each project or program, the Stakeholder Map and the Influence / Interest Map should be regularly revisited and checked to see whether other stakeholders have now appeared, new interests have emerged and whether earlier assessments of stakeholders should now be modified.

So revising the initial collected information throughout the program is crucial to ensuring appropriate communication strategies and approaches for stakeholder engagement.

And a timely stakeholder analysis can help a project or program manager identify potential conflicts or risks, expectation misalignment as well as changes and opportunities.

Business Analyst: An evolving position

The BATimes published in late 2008 an article [1] about trends in Business Analysis (BA) and Project Management (PM) for 2009.The article highlighted the following points:

• Convergence of PM and BA roles
• Greater emphasis on requirements in project management
• Change in requirements approaches
• Increased use of “Agile” approach and techniques
• BABOK continuing to have an impact
• Business Intelligence (BI) continues to grow
• Less budget for conferences and training

Before any further comment on these statements, let’s turn back to the past and see how BA has evolved in the last half century [2].

In the 1960’s a software crisis started. This crisis has several origins. First, the computers were becoming more and more complex and powerful. As a consequence, software was becoming more and more complex. At this time, software engineers were not aware about business needs, needed to spend a lot of time learning new upcoming programming languages, tried to organize their development teams… Lots of projects failed, and finding solutions took a while. During this crisis, engineers understood that software development is a complex task, and figured out later that there is no single silver bullet that will address the issues faced in developing software. Still in the 60’s, the need for BAs in software projects became essential.

Defining the role of the BA has been a long process, and another crisis, in the early 2000’s, changed the industry. This crisis brought the generalization of IT outsourcing. Since then, the main trend regarding the organization of labor in IT projects has consisted of the elaboration of teams on vertical capabilities rather than horizontal. This means that instead of having a team of BAs, a team of developers, a team of testers, the idea of using cross functional teams in IT projects is now widely accepted.

Concerning the business analyst, we can find a good definition in the article “What is a business analyst” [3]. This article says that a BA is a communicator, facilitator, subject matter expert, designer, trainer, planner, manager… Indeed, the BA is in contact with all the participants of an IT project, going from the client to the final user, going from the project manager to the test manager. Back in the 60’s, nobody in an IT project developed the business side of projects. Development teams were all coming from engineering without business awareness. Today’s business analysts must be more versatile, keeping technical skills and being aware about commercial matters and business processes.


What about the future?

Back to our BATimes article [1], the skills required to be a BA have not change. The article just mentions a refinement in the role of the BA and the trend for emerging techniques.
In the last 50 years, the BA community has not been very well organized. Many techniques have been tried, experienced, combined, and tuned. The formal organization of the BA community started in 2003 with the creation of the International Institute of Business Analysis (IIBA) [4]. With this institute, some BAs started working on the “Body of Knowledge” (BABOK), which gathers the commonly used techniques. We expect this book to be more and more utilized by the BA community. We expect in particular an increased use of “Agile” techniques.

On Agile projects the primary role of the BA is to facilitate clear requirements, rather than document them or elicit them. The Business Analysts becomes more people focused and he is more involved in understanding the drivers, values and context of the business requirements than the details of the requirements themselves. Communication and a clear transmission of the requirements to the development team become crucial.

So BAs will have to provide their analysis using more graphical explanations, and less text based documents. BAs will have to refine as well their system knowledge so as to be able to draw out functional requirements from the product owner and if necessary translate them into more technical language for developers.

We expect also for 2009 a growth of Business Intelligence needs.

Business Intelligence theory looks at certain factors to make high quality decisions. These factors include customers, competitors, business partners, economic environment and internal operations. Relying on this analysis Business Intelligence can help BAs focusing on true business requirements and anticipating how clients will use their data.


At CTP we keep abreast of the latest techniques concerning business analysis and project management in order to offer the solution that better fits our customer needs. That gives us an edge in the provision of top class advisory services to our clients.

References:
[1] BATimes, Trends in Business Analysis and Project Management to watch for in 2009, E. Larson and R. Larson, December 2008
[2] Businessanalyst.wikia.com, Business Analysis: a potted history, unknown author, March 2007
[3] Businessanalyst.wikia.com, What is a business analyst, unknown author, December 2006
[4] International Institute of Business Analysis http://www.theiiba.org/

Project Success Assessment

Enter “Project Management” in the search field of Amazon and you get over twenty-eight thousands book titles. Just in the last 30 days, the online merchant has added more than forty new releases in this area of its library; that’s more than one book per day.

Project Management methodologies have been standardized, best practices are abundantly documented, and roadmaps to successfully execute a project are plentiful available. Then why does the Standish Group comes with the Chaos Report 2007 stating that a staggering 65% of the projects can be defined as “challenged” (over time, over budget, and/or significant functionality missing) or outright “failed”.



Top-10 factors affecting the outcome of a project

The Standish Group and many other authors have created their top-10 factors affecting the outcome of a project. These lists are very similar and most of them include the following items:

• Incomplete and/or changing requirements
• Low end-user involvement
• Low resource availability
• Unrealistic expectations
• Little executive support
• Little IT management support
• Lack of planning
• System / application no longer needed
• Bleeding-edge technology
• Other / miscellaneous

Once again, it seems rather difficult to understand why with so much knowledge at hand and well listed pitfalls, only 35% of the projects are completed on time, on budget, and on target.

The main reasons for these numbers can be attached to the fact that project management is not an exact science. The outcome of a project is impacted by unquantifiable human factors, by immeasurable business variables, and by incalculable external hazards. To alleviate these threats, the good project manager establishes a risk list giving him a gut feeling about his chances of success.

Project Success Assessment Tool

To replace this “gut-feeling” by more tangible numbers, Cambridge Technology Partners uses a tool allowing its consultants to rapidly forecast the success of technology projects and to help them focusing on the most threatening factors.

CTP uses its own experience combined with the statistics published by the Standish Group to assign a probability to each factor.

for example:
“incomplete and/or changing requirements” is defined to represent on average 25% of the risks acting against the successful completion of a project.
Then for each item of the list, the project manager associates a risk scale from 0 (minor risk) to 5 (major risk).

By multiplying each risk probability with its associated risk scale, and by adding all these results, the user obtains a total score. This total score is finally compared to a scale assessing your chances of project success and the actions that may be required.

The Figure 2 below shows the project success probability for the hypothetical implementation of an ECM solution. The table clearly demonstrates that the project manager should work on the risks related to the requirements and the expectations before going any further.

The tool is based on the Standish Group’s “Top 10 Chaos” and Ron Smith’s work (Project Manager at BMC Software in Houston)

Please contact Cambridge Technology Partner if you like to have a copy of the Project Success Assessment tool. If you use it, please, provide us with your feedback, so we can improve it or help you in any other ways to put your projects on the right tracks.

Cambridge’s project managers are incented to become Project Management Professionals (PMP), certified through the Institute, as well as participate in continuing education programs. Its business analysts are following a similar path towards IIBA certification from the International Institute of Business Analysis.