Swiss ICT Awards 2010

Ok, this is not really a Advisory Service article as we usually post here on the blog - just a small company advertisement where you might help out. CTP has been nominated by the Swiss ICT Awards 2010 in the category "Champion". This award category gets selected by a jury. For the PUBLIC category, you can actually place a vote!

Please click on the below link and vote for Cambridge Technology Partners now and we may become the winners of the PUBLIC category:

http://www.swissitmagazine.ch/index.cfm?pid=7786&cid=2103

Thanks!

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.

Presentation Skills Checklist

Presentations are one form of communication - a very important form. The way we communicate dictates a great deal of how successful we’ll be in our careers. In your own experience is “success” more strongly tied to technical ability or to one’s “presentation”? In reality, both are important. Your ability to communicate greatly impacts your success on both project and career levels. But presentation skills are not something that people are born with, they have to be fostered.

As a Business Analyst or Project Manager good presentation skills can make life easier. Here is a checklist that can be used to be well prepared.

SLIDE CHECKLIST

• Storyline (logical flow) first, slides follow. Use “trackers”* to support the storyline.
• Be consistent; follow corporate format and color guidelines
• One message per slide. Visually highlight key words to draw audience’s attention to the most important elements of each slide.
• Make your presentation multi modal; use text and graphics together
• Visuals need to support the message
• Keep it simple; use short sentences or abbreviations known by the audience
• Make it readable (scan-able)
  In a complex chart, use arrows or symbols that draw attention to the important part of the chart (data points should be well placed and easy to read or deleted).
• Spelling is important. Review your slides and then ask someone else to look at them next.
• If used, make sure all animation work properly
• No client confidential information and new inherited names and definitions
• Include a meaningful title on your slides
• Include a table of contents, an agenda
• Use hidden slides for additional information when answering questions and for nice to have information
• Always expect that slides may be viewed without verbal explanations. Prepare all possible print formats with the proper headers and footers. Assure printability (in black & white) and write speaker’s notes to make your presentation self-readable. It will allow a third person to take over your presentation in case you do not show up.
  

Slides are only one element of successful communication. In the planning stage, allocate a maximum of three minutes for each slide, to help you stay on time during your actual presentation.

TALK CHECKLIST

• Rehearse until it becomes second nature and you can concentrate on your audience.
• Be prepared; get to know the audience to avoid stage fright. Test your setup before the presentation.
• Plan for monitoring time
• Prepare a strong opening: grab audience’s attention: ask question or open with an impressive statistic. Explain your objective.
• Establish rapport and credibility: start on time, show you’re prepared, introduce yourself
• Know the main point of each slide, in order to avoid distracters (repeated non-words like “uh … uh…”. Pass to next slide after having introduced its main point.
• Beware of your
• Appearance dress code
• Facial expression smile!
• Eye contact avoid reading from the slides and keep eye contact with all audience members to gather non-verbal feedback.
• Voice audible, normal pace, energetic, articulate, varied pitch. Pause before and after major ideas.
• Body language good posture, open, palm-up gestures
• Gestures and movement use hand gestures to emphasize and illustrate, move to address both sides of the room. Never put hands in your pocket.

• Set an interactive climate by asking questions
• Closing: summarize what was accomplished, include call to action
• If needed, press ‘B’ or ‘W’ to make the screen go black or white, so that the audience watches you. Press any other key to go back to the presentation.
• Turn off your screen saver
  

Business Analysis & Web 2.0

There is an interesting post written by John Brunswick about the business need for web 2.0 technologies. I think, the business analysts together with the technology specialist at CTP fully support his view to have the business need in the center of any solution.

Here a short extract from his post about "Enterprise 2.0 Success – Focusing on Business Needs":

Final Thoughts
There is not doubt that a range of social computing technologies in the enterprise can assist businesses to run more effectively. However, we want to make sure that we do not implement technology in search of a problem. The challenge is connecting them with the business in the right way. Do not find a use for tagging, blogging, wikiing. Find the business need or pain point – then examine what technologies best support meeting that need or eliminating the pain point. Hopefully some of the above questions can help your organization to focus, clarify and be successful with where and how these emerging technologies can benefit your company.

Future of Enterprise Portals

Definition

A portal is a framework for integrating information, applications, and process across organizational boundaries. At its core, portal technology provides an integrated visual display of multiple information sources and business applications together with tools to enable rapid customization, personalization and configuration of those resources by end users, administrators and resource providers. Portals are critical part of an enterprise's technology and business strategy, enabling teams to collaborate, innovate, and learn.

Gartner defines the portal as a Web software infrastructure that provides access to, and interaction with, relevant information-, knowledge-, and human assets by select targeted audiences, delivered in a highly personalized manner.

Challenges and Problems

Although nowadays enterprise portals are widespread and have a history of almost 10 years, it is still a comparatively immature technology. Portals are suffering from performance bottlenecks, reduced usability, navigability, and find ability. Enterprises are facing implementation delays, cost overruns and poorly integrated or conflicting contents.

According to AMR Research (April 2006), 51% of companies are fully operational with portal software. The companies report a mean budget of $4.3M, representing 22% of the total IT budget in 2005. Budgets rise to a mean of $5.1M in 2006. The main business drives for portals are the efficiency, collaboration and the bridging between IT and business.

Future of Portals

Tomorrow's users will demand a different set of portal capabilities and the users become the center of their own “portal universe”. Portals will serve as the primary entry point for enterprise mashups. According to Gartner (April 2007), the future of portals is mashups, service-oriented architecture (SOA), and more aggregation.

A mashup is a Web site or a Web application built in light weight manner, combining content from multiple web sources into an integrated presentation. Gartner says (May 2007) that this is a disruptive technology (i.e., drives major change in business processes or revenue streams, consumer behavior or spending, or IT industry dynamics). By 2010, Web mashups will be the dominant model (80%) for the creation of composite enterprise applications.

Portal vendors will decompose their portal products along service-oriented lines and portlets, thus increasing the reusability. 80% of all software development would be based on SOA by 2008. The Web is emerging exponentially: Web 2.0 technologies and the increasing number of Internet users (1.2B) contribute to the so called architecture of participation. On the Internet are already existing large repositories of building blocks (widges, gadget, badge), which make possible to create is short time, reliable Web pages even by non-professionals.

Aggregation will be in the focus. Personal portals will be the home page for many aggregators, with big players like: Windows Live, My Yahoo and Google.com.

Portal interoperability will be supported across five touch points: portlets, user profiles, directory, security, metadata.

Trends, Perspectives

According to McKinsey (June 2007), 66% of executives plan to maintain or increase their investments in technology trends that encourage user collaboration (peer-to-peer networking, social networks, Web services). Companies are using some combinations of Web 2.0 technologies in order to interface with the customer (i.e, marketing, 70%,) and to manage collaboration internally (i.e., knowledge management, 75%).

Content management (Vignette) and other software companies (Oracle) are aggressively pushing portal products. Companies will bundle portal and content management offerings following the “Google enterprise mantra”: should be easy and fast to install and extremely usable. Presently, it is too much time and money is spent solving technical problems rather than business ones.

Gartner says (June 2007) that EMEA portals, process and middleware software market revenue increased 16% in 2006. Furthermore, 44% of EMEA IT managers intend to increase their software spending in 2007, having high interest in SOA projects. Software spending is higher in countries where the economy highly depends on organizations that see IT as an essential component of a successful business strategy: Scandinavia, CH, Ireland, UK. Nevertheless, in the next 5 years, Eastern Europe is expected to be at the forefront of growth in EMEA.

Portal vendors

Oracle (BEA): As announced in the strategic webcast beginning of July, the only strategic portal product is Oracle WebCenter Suite. BEA WebLogic Portal (WLP), Oracle Portal as well as AquaLogic User Interaction (ALUI) are listed as product to be continued & converged.
The WebCenter Suite contains most collaborative components of ALUI already. This I somehow discovered in the official description now. So it seams that ALUI has converged much quicker than WLP (if that is going to be converged at all). Oracle has a clear Web 2.0 strategy: social tagging, end-user-driven mashup creation and supports relevant portal standards (WRSP).

Microsoft offers an integrated suite delivering portal with content-, workflow-, and project management, collaboration, search and business intelligence functionality through the Windows SharePoint Services (WSS) and Office SharePoint Server (OSS) 2007. It is based on single repository. SharePoint is seen as a Web 2.0 platform (ecosystem) that can support both internal capabilities as well as leverage external best-of-breed products: integration of wiki solutions (Confluence, SocialPoint) and RSS feeds (SocialSites). As cautions it can be mentioned, that larger early adopters have not yet completed their implementations and there is room for improvement in management and replication functionality.

Other CTP Updates regarding Portals

The CTP Java Community Blog publishes a monthly portal update considering more portal vendors. So far they published a post for

• Portal Update - August 2008
• Portal Update - July 2008
• Portal Update - June 2008

How a Traceability Matrix can help you keep track of your Requirements

During a project life cycle everybody tries their best to keep the final implementation in line with the initial user requirements. But very often, the actual implementation fits only partly with the user requirements. A simple but effective tool to avoid this scenario is the Traceability Matrix.

Common challenges managing user requirements

IT projects often start with the definition of the requirements (user, functional, others):

• A business analyst talks to the end-users and gathers their requirements. Afterwards the functional requirements based on the user requirements are specified.

In a next stage of the project the system design specification is created:

• A solution architect creates the design specification for the application to fulfill the functional requirements. He will make some interpretation how to functionality should be implemented, most likely not knowing the original user requirements.

In the implementation phase, chances are high that the developer does not know the user or functional requirements. Therefore he will mainly focus on the technology aspect and not so much on end-user expectations. This is even more pronouncedly the case when the developer belongs to a different team or even company than the business analyst who gathered the user requirements.

At some point the test cases are created and since it is difficult to know which part of the application matches which requirements, often just the functionality of the implementation is tested and not the user requirements.

To make things worse, in the course of the project, there will be changes from different sides:

• The user might have new ideas and the developers could face some technical difficulties. The changes most likely will be communicated to the other parties in the project, but usually it is not very clear which parts are affected. Therefore implementation starts diverging more and more over time impacting the initial user requirements.

What is a Traceability Matrix

The Traceability Matrix keeps track of the connection between user requirements, functional specification, design specification, test cases and potentially use cases. In each phase of the project the appropriate person fills out the one part of the matrix which belongs to his topic. Each element is linked with the element it is based on, starting with the user requirements.

A Traceability Matrix document owner ensures that any change of an item is also reflected in all the linked items. Therefore, if a user requirement changes, the linked functional requirements, design specifications and test cases have to be checked and adapted if necessary.

How does the Traceability Matrix work

In your spread sheet tool you create a table with columns for the topics you want to track in your Traceability Matrix. Normally you start with the user requirement, but in special cases you could also start with the uses cases.

1. State the reference numbers of the user requirements. One for each row.
   
   
2. In the next step add the functional specifications reference numbers belonging to the user requirements per row. The same functional requirement can appear in several rows.
   
   
3. Then you go on the same way with the design specification and the test cases.
   

You will end up with a nice Traceability Matrix, where you can check which elements are linked together. At which time you add use cases and test cases depends on your processes.

If you like you can improve your spread sheet with mechanism to highlight if an element in the chain is missing.

What do you need to keep in mind while using the Traceability Matrix

The Traceability Matrix is a very helpful tool, but as with any tools, it needs to be used properly to really be effective. Here some tips, what you should keep in mind, when using the Traceability Matrix in your project:

• Get people to feel responsible for their part: They will fill it out properly and also be interested that the rest of the document is filled out, so they can work with it.
  
  
• Fill it out while you are writing your document: This saves a lot of time, because afterwards it is a hassle to link all the elements. In addition it helps to ensure that you don't forget anything.
  
  
• Always keep things up-to-date: Maybe the key for a successful use is to always update the Traceability Matrix and all the other documents. Only then you can easily check something and make adjustments where needed.
  
  
• Do your test cases early on: Thanks to the Traceability Matrix it is even easier to do so. Like that you can ensure that they are really based on the user requirements and the developers can easily check which test case their implementation has to pass.
  

We hope that this little summary about the Traceability Matrix will help you to manage your requirements more efficient. If you would like to know or need support in this area, feel free to contact us anytime.

Setting the context for Advisory Services at Cambridge Technology Partners

Statistics on IT project delivery
Although there has been some improvement on IT project delivery since the Chaos Reports was first published in 1999, the situation has unfortunately not changed dramatically. 2/3 projects are still canceled or challenged, and only a 1/3 are truly successful.



There are also some other statistics which can be found in all kinds of reports:

• $80 -145 billion per year is spent on failed and canceled projects (The Standish Group International, Inc.)
• 60% - 80% of project failures can be attributed directly to poor requirements gathering, analysis, and management (Meta Group)
• 40% of problems are found by end users (Gartner)
• Poorly defined applications have led to a persistent miscommunication between business and IT. This contributes to a 66% project failure rate for these applications (Forrester Research)

If you want to be part of the 35% successfully delivered projects, CTP can help you with our Advisory Services offerings.

Cambridge Technology Partners offers

1. Project Management as a service
   
2. Business Analysis as a service
   
3. System Architecture as a service
   

We bundle our core knowledge coming from different areas of expertise to offer Services to our customer to overcome the well know challenges.



Projects bring together resources, skills, technology and ideas to achieve business objectives.

Project management helps to ensure that these objectives are achieved for the defined scope within budget, within time and to the required quality.

• CTP is the pioneer of the fixed time / fixed price approach and an early adopter of strong delivery and project management methodologies
• CTP continues to tailor its methodology to new business challenges, including Global Sourcing & Global Testing

Business analysis helps to identify business needs and determines requirements to meet business objectives.

• With our knowledge and techniques, CTP can quickly identify, develop and prioritize business requirements.
• With strong facilitation and communication skills CTP can help to close the gap between Business and IT.
  

System Architecture ensures that your defined business requirements fit into your IT landscape.

• Our experienced system architects at CTP will turn your business requirements into your IT solution.

The entire CTP Advisory Services Presentation is available at our CTP knowledge repository: Link (internal network); Link (vpn-portal)