Evaluation and Selection of IT Solutions based on ...

Evaluation and Selection of IT Solutions based on User Requirements Management Dr. Evangelos Markopoulos. Managing Director EMPROSS Strategic IT Consultants [email protected] www.empross.gr

CITEA - 3rd Conference of ICT, Nicosia Cyprus, 8-10-2008

Dr. Evangelos Markopoulos. Evaluation and Selection of IT Solutions based on User Requirements

Presentation Structure 1. The Concept of Technocracy and Technocratic Development (Towards the identification of what we are capable to do)

2. The Requirements Process (Towards the identification of what we want to do)

3. Requirements based Project Management (Towards the identification of how we can make sure that we will practically accomplish what we want to do)

4. The Technology Selection and Evaluation process (Towards the identification of how to acquire what we want to do)



Presentation Structure

SECTION 1. The Concept of Technocracy and Technocratic Development (Towards the identification of what we are capable to do)



The Software Crisis IT Solutions are basically Software Oriented Solutions. Software realizes the User needs while hardware supports the software operations.

As software demands increase the IT solutions become more and more complex. Unfortunately this leads to a new generation of the software crisis. On the other hand, just like it was before, for every crisis, sooner or later a management plan is being develop. We hope that the international ICT community will come up with one this time too.



The Software Crisis

In the 2000’s

??? In the 90’s In the 80’s

The HARDWARE crisis

The PEOPLEWARE crisis

The HARDWARE crisis



Technocrats, Technocracy, Technocratic Organizations and Technocratic Development Technocrat : the goals

The one who aligns the needs and the capability with

Technocracy : The systematic alignment of the needs and the capability with the goals Technocratic organizations : The organizational alignment of the needs and the capability with the goals. Technocratic development : The support to the efforts of any new or existing enterprise to be rebuilt and transformed through technocratic initiatives.



Technocratic vs Technological Development The technocratic development sounds similar with the technological development but it is quite different. Technological development of an organization is based on the transformation of the organization using state of the art technology on all or almost all of its activities. On the other hand technocratic development of an organization is based on the use of the technology that is needed at a given time and that is being capable to be used successfully. Technocratic organizations are the ones not being carried away by the ‘WOW’ but question the ‘HOW’



Technocratic vs Technological Development In other words a technocrat is not being carried away by fascinate technological break-troughs and state of the art ideas, product and concepts. A technocrat has a more conservative profile taking one step at a time, or making breackthoughtds knowing that is capable to carry them out successfully.



The Technocratic Maturity Concept A technocratic mature organization is the one that knows its capabilities and relates them with its goals. Based on theses capabilities the organizations adopts only the technology that can be used and can help the organization succeed. If technology is vital to other processes in the organization that are not mature enough to adopt it, then the technological insertion is being planned slowly while working towards raising the technocratic maturity of both the people and the processes.



Technocratic Development based on Organizational Maturity The integration of the technocratic development concept and the technocratic maturity concept is the recipe for the development of technocratic organizations. Mature organizations know their goals and capabilities, while technocratic organizations are being developed based on those goals and capabilities. The balance between goals capabilities and technology is the overall recipe for successful and secure organizational development.



Technocratic Development based on Organizational Maturity In technocratic development organizations must have goals and visions. Goal and visions need to be achieved based on a strategy. A technocratic strategy uses two prime components. The people that will perform the work and the technology that will assist the people to perform the work with more efficient, accuracy and security. The balance between the people and the technology is vital to the development of the organization.


Dr. Evangelos Markopoulos.

Evaluation and Selection of IT Solutions based on User Requirements

Technocratic Development based on Organizational Maturity It is often recorder a dispute between the technology people and the management people within any kind of organizations. IT departments are considered cost centers while marketing or sales departments are considered as profit centers. This misconception leads to an unstable organizational environment and any goal can be considered unreachable. Lack of technological support in the organizations operations results to lack of qualitative and quantitative operational activities. Technical and operational staff in organizations need to be considered equal a be developed with common practices that can support the alignment of both with the corporate vision. CITEA - 3rd Conference of ICT, Nicosia Cyprus, 8-10-2008


People Centric Organizations Viewing technology as cost center.

N O I S VI

Visions fail. Lack of technology results to Bureaucracy.

II TT

(Informa(Information tion TechnoTechnology) logy)

NO Process Alignment can be achieved

H H R R (Human (Human Recourses Recourses

Organizational Operations (Services, Productions, etc)



Technology Centric Organizations Viewing people as simple users.

VI SI O II TT (Informa(Information tion TechnoTechnology) logy)

N

NO Process Alignment can be achieved

Visions fail. Lack of people results to lack of initiatives and strategy execution.

H H R R

(Human (Human Recourses Recourses




Visions can never fail. Goals have been developed based on the organizational capabilities.

Technocratic Mature Organizations Viewing technology and people as equal strategic elements.

II TT

VISION Alignment with

Processes

(Informa(Information tion TechnoTechnology) logy)

(TQM, CMM, Kaizen VSN BPR etc.)

H H R R (Human (Human Recourses Recourses




SECTION 2. The Requirements Process (Towards the identification of what we want to do)



Why Projects Fail ?

The complexity for managing an information technology project has been carried along through the complexity on understanding the user needs and their expectations from technology.



Why Projects Fail ?

In 1982 when the U.S. Department of Defence (US-DoD) after an investigation held by the General Accounting Office (G.A.O.) announced that only 2% of the information technology systems were functional at delivery, 3% could function with the implementation of additional changes, 19% functioned but they were quickly abandoned, 30% were never delivered although they were totally paid for, 46% were paid for, delivered, but never functioned. The prime cause of all these failures was insufficient requirements management processes which lead to incorrect and improper project management, causing projects to be financially unpredictable, unprofitable, operationally risky, insecure and/or of bad quality.



Why Projects Fail ?

U.S. DoD G.A.O Projects Evaluation Report Never Functioned but paid in full 46%

Successfully Delivered 2%

Operate after additional changes 3% Operated but abandoned 19% Never Delivered but paid in full 30%



Why Projects Fail ? Jones Carpers book on ‘Patterns of Software Systems Failure and Success’ indicates sixteen success / failure factors. Nine of them are project management related, indicating the lack on planning, estimating, tracking, progress reporting, milestone control, risk management, configuration control and above all bad requirements. Carpers also relates the success / failure project factors with social factors related to the management practices. The ones that stand out the most are the ones related with the human factor and the project management maturity of the ones performing project management. The lack of communication and process interpretation are the most significant ones with the upper management in a negative role.



Why Projects Fail ? The ‘Chaos Report’, by The Standish Group International, Inc. also indicates the requirements process as the most significant one for most of the disasters. Almost 42% of the successful project factors were based on the user involvement, the requirements quality and the executive management support. In a similar way almost 45 % of project failure factors were based on lack of user input, incomplete and continuously changing requirements and lack of executive management support. The report states this crisis by indicating that 31% of the projects studied was cancelled before completion, 53% of the projects overran by 50%, and only 9% of projects in large companies delivered on time and within budget,.



Why Projects Fail ? Loosing track of the requirements leads to loosing track of the project implementation process, since requirements affect significantly the implementation strategy. The cost of catching a missed requirement and correcting it in the analysis phase of the implementation process is nearly from 0,1 (10%) to 0,2 (20%) more than the initial requirement implementation cost. The cost of catching and fixing a missed requirements in the design phases is 0,5 (50%), in the coding phases is 1,0 (100%), in the unit test phase is 2.0 % (200%), and in the acceptance test phases is 5,0 (500%) more than the initial requirement implementation cost.



Why Projects Fail ? As users understand the power of technology, they keep on coming up with requirements that stretch the system’s implementation capabilities to the maximum. On the other hand, managing complex and also incomplete requirements makes project management look like a Herculean task. This phenomenon has made no methodology, standard or guideline, to be able to stand as a tool or best practice towards managing all types of information technology projects. Every project today seems that it needs a unique project management approach, which must balance the project’s technology constraints, user constraints and volume constraints. Understanding the environment and the constraints around the project is significant towards drawing its implementation management strategy, but understanding the project requirements is actually critical towards executing a project implementation and management strategy.



What is a Requirement ? A requirement is something that a project must do or a quality that the project must have. A requirement exists either because the type of the project demands certain functions or qualities, or the client wants that requirement to be part of the delivered product. Groups of requirements define product or system functionality and groups of functions define the operations and of the entire product or system. The requirement is the beginning and the end on any initiatives, either developing a system / product, or acquiring a systems / product.



What is a Requirement ? Systems or product requirements can be categorized requirements, non functional requirements and constraints.

in

functional

The functional requirements are the ones directing the functionality of the product / project. They are the ‘must do’ requirements, supporting actions that Non functional requirements, usually attached to the functional requirements, are properties or qualities that the product developed must have. In some cases the non-functional requirements are critical to the products success, and other times are just requirements because they enhance the product. Constraints, finally, are global requirements. They apply to the entire product and are preferably defined before beginning work on gathering the requirements.



Requirements Management Process

Loosing track of the requirements and the project goals, and expectations as well is not very difficult. The requirements need not only to be well defined but also verified and aligned with the expectations and goals of the project. A common problem in project management and specifically in requirements management is that the existence of requirements does not guarantee the correctness of the requirements and their contribution on the project.




Moving from the perceived requirements to the fulfilled requirements, is very easy to lose control of what is finally being developed, if effective requirements management processes are not in place before, during and after the implementation of a project. The requirement process needs to be redesigned conceptually and practically. A project begins with requirements in the project identification phase, far before the project implementation phases. The initial, vague, and incomplete requirements form the structure of the project and based on this structure they are getting evolve along with the maturity of the project owner.







actual needs

perceived needs

expressed expectations

selected requirements

call for tender

design and development

specified requirements

proposal

customers’ satisfaction: quality view

delivered product: fulfilled requirements

conformance: contract view




What is Requirements Engineering? Requirements Engineering can be defined as the systematic process of developing requirements through an iterative co-operative process of analysing the problem, documenting the resulting observations in a variety of representation formats, and checking the accuracy of the understanding gained.




Requirements RequirementsEngineering Engineering

Requirements Requirements Development Development

Requirements Requirements Elicitation Elicitation

Requirements Requirements Analysis Analysis

Requirements Requirements Management Management

Requirements Requirements Specifications Specifications

Requirements Requirements Validation Validation




Requirements Elicitation. Requirements elicitation is the activity during which software requirements are discovered, articulated, and revealed from stakeholders or derived from system requirements. Sources may be system requirements documentation, customers, end-users, domain specialists or market analysis.



SECTION 4. The Technology Selection and Evaluation process (Towards the identification of how to acquire what we want to do)



Technology Selections Challenges Management challenges Decision by Committee Authority (project owner) Buy-in participating of shareholders. Business Case / Lack of Support

Process Challenges Implementation process Management process

Technical Challenges Solution adjustability Technology complexity User complexity



Project Identification Definition of the Project Articulating Objectives (objectives, goals, metrics, etc) Reviewing the Role of Technology

Selection Considerations Functional considerations (project considerations) For example, in a project to select a Content Management System, Technology Options Content Entry Workflow Build – custom build / Content Categorization integration User Administration Buy – third-party products Archiving Lease Template and Design Management Open source software Business considerations Time to Implement. Budget. Total Cost of Ownership Change Management Business Opportunities / Strategic Goals. Internal Resources Maturity of Technologies Risk Tolerance Technical considerations Security Performance Reliability Scalability Portability Interoperability Compatibility Data Exchange: Support. Ease of Use or Usability CITEA - 3rd Conference of ICT, Nicosia Cyprus, 8-10-2008


The Technology Selection and Evaluation process - at a glance -

1. Be e Technocrat (guidelines on section 1)

2. Identify your Requirements (guidelines on section 2)

3. Manage your Requirements (guidelines on section 3)

Because …. If you do not know where you want to go… … no map can help you.



THANK YOU Please contact us for further information, documentation, questions and clarifications.

Dr. Evangelos Markopoulos Managing Director EMPROSS S.I.T.C. Athens, GREECE [email protected] www.empross.gr



SECTION 3. Innovative Techniques on Requirements based Project Management (Towards the identification of how we can make sure that we will practically accomplish what we want to do)



Managing Development and Acquisition Projects by Pivoting the Requirements Process

The requirement can be perceived as a living organism, or as reference point to every engineering activity that supports any development life cycle process under any development model. By pivoting the requirement process the requirements become the base that enables project tracking and measurement on even human resource management activities, to enter into the so called ‘engineering practices’, transforming this way a system development methodology, into a systems development framework.



Managing Development and Acquisition Projects by Pivoting the Requirements Process Process PIVOT

Re Analysis q u i Project r Planning e m Design e n t Develos pment

M g m t

Project Management Activities

Integration

Testing

Documentation

Installation

Opera-tion

P P r ro o j. j. T T e r a M M a m g g c m m k M t t i g n m g t C h a n g e

R i s k

Acceptance



Managing Development and Acquisition Projects by Pivoting the Requirements Process Once the requirements have been identified the development project begins. Using the requirements management process as pivot in the effort to manage the development process, the requirements document leads a series of inspections, reviews and walkthrough in all development phases. Base on the requirements, the analysis of the system is being executed, inspected and accepted. The system design inherits the system analysis deliverables and the design of the system is generated in such a way that all requirements passed from the analysis, are included in the design. Design reviews are conducted to verify that the design is also aligned with the requirements and the analysis as well. The same process is applied consecutively in all other development phases as well. If deviations from the requirements are found, they must be defended and documented in order to be accepted or rejected by the project management and quality assurance teams. CITEA - 3rd Conference of ICT, Nicosia Cyprus, 8-10-2008


Product Assessment

Project Development Structure

System Requirements

Process PIVOT R

E Q U I R E M E N T S M A N A G E M E N T Ν

Re-Usability Systems Analysis Systems Design Prototypes

H/W accept/validation

Parameterization System Implementation System Installation . System Testing

Coding (Custom) (Custom) COTS

System Documentation System Acceptance Training Systems Operations

Migration / Porting Inter-Operability Integration

Post-Completion Analysis

System Maintenance



Project Assessment

Tender Management Proj. Management Structure

Multiple Project Management Coordination

Project Planning

Project Implementation Implementation of Project Requirements Project Management Documentation

Project Tracking

Process Peer Reviews PIVOT

Communication Management Project Inspections / walkthroughs

Project Libraries Management

Change Management Configuration Management

Project Evaluation

Quality Assurance Standards Management Subcontractor Management Risk Management / Contingency Contract Management Metrics (Productivity, Progress) CITEA - 3rd Conference of ICT, Nicosia Cyprus, 8-10-2008



The requirements pivoting concept can also be applied in the system acquisition methodologies and initiatives. Managing the acquisition effort is based heavily on managing the projects requirements quantitatively and qualitatively. The requirements can take the leading role the on the system acquisition process by defining the project, leading the tendering process, support the projects contract and track the project implementation. Once the project has been identified and the project requirements have been created, the tendering process begins with the development of the request for proposals and the evaluation of the suppliers’ offers.



… based on the needs Requirements Requirements

Process PIVOT

… based on the requirements

Request Request for for Proposals Proposals … based on the RFP

… based on the RFP responses

Contacting Contacting

Acquisition Management

Project Implementation

Subcontr acting 1-n …based on the contract

…based on the methodology




The requirements in this case, provide the raw material for implementing the tendering process. The requirements role on an system acquisition project supports heavily the implementation period of the project. During the project implementation, the requirements are used to track, inspect and review all project implementation processes and activities performed by the supplier.



Process PIVOT

Scope Requirements management Project Proposal

Plans for resourcing

Project Planning

Management structure

Beginning of Project Implementation Contract Tracking and Oversight Evaluation Project tracking and oversight Deliverables management Quality Assurance Change management Risk management End of Project Implementation Transition & Support

Acceptance Post-Impementation Eval.



Systems development and systems acquisition process mutation. The total project implementation or project acquisition phases could possibly be represented by a mutational information technology project management model, where each stage and even more each stage activity could be supported by a specific management technique, method or approach. On the other hand it is widely accepted that each project must follow a specific project management method in order to assure consistency on its development management and also maintenance effort. Unfortunately no methodology can be considered as the silver bullet or the one that can successfully support all management goals and objectives under all project constraints. It is clear that a methodology besides the need to be readjusted on the environment of each project, and not only to the goals and objectives of each project, must also be readjusted to the needs and objectives of each implementation phase on each project. CITEA - 3rd Conference of ICT, Nicosia Cyprus, 8-10-2008


Systems development and systems acquisition process mutation. Development Implementation Process Project Implementation Stage

Acquisition Implementation Process

I.E., LCM-AIS, DοDSTD- 2167A

Project Planning Stage

SΑ-CMM, ITIL, ITPM, WWPMM

Project Implementation Planning

PROMPT, PRINCE, PRODIGY, etc Project need formalization Project Identification Stage SDPP, RDPP, COCOMO, FPA, etc.



Systems development and systems acquisition process mutation.

In such project management process transformation need the mutational project management concept can be complementary on the agile project management concept since both are based on the readjustment of the management processes on the project needs affected by the project’s environment. The difference between project process transformation and project process mutation is that the agility of the process transformation, which is the adjustment of the processes, is replaced with the agility of the process mutation which is the replacement of the process with other more suitable process in order to meet the specific process goals and objectives per case and per instance.



Systems development and systems acquisition process mutation. Process Mutation in Project Management Frameworks A project management framework, unlike a project management methodology has the flexibility to be adjusted to the project needs, goals and constraints. A framework can be consisted from many phases and many processes per phase, where a process transformation takes place every time a new project is introduced. Process frameworks are characterized by the agility concept. In frameworks there is a method, an approach, a standard, a philology, a logic, but no strict rules, specific phases, specific process or process dependencies.



Systems development and systems acquisition process mutation. Next Stage Indicative Systems Acquisition Framework

Requirements Analysis

Next Stage

Design

Requirements Mgmt

Change Mgmt

Implementation

Contract Mgmt

Testing Documentation

Project Development Process

Installation Planning Stage Indicative Systems Development Framework

Risk Mgmt

Project Tracking Planning Stage



Systems development and systems acquisition process mutation. Project Mutation Stages The identification and determination of the project management approach is the first project management mutation within a project management framework. If the project is difficult technically to be implemented then emphasis will be given on engineering processes and technical management approaches, instead of a planning and tracking oriented approaches. 1. Project Definition Stage 2. Project Estimation Stage 3. Project Implementation Stage 4. Project Planning Stage 5. Project Support Stage CITEA - 3rd Conference of ICT, Nicosia Cyprus, 8-10-2008


Project Support Stage

Project Support Maintenance

PROJECT MUTATION 5

Project Operations Stage

Project Operations Support

PROJECT MUTATION 4 Requirements

Project Implementation Stage

Analysis Design Implementation Testing Documentation Installation

PROJECT MUTATION 3


Project Implementation Plan

PROJECT MUTATION 2

Project Estimation Stage

Project management mutational model for implementation process of information systems.

Project Implementation Estimation

PROJECT MUTATION 1

Project Definition Stage

Project need and Definition

PROJECT START




Project Support Maintenance

PROJECT MUTATION 5



PROJECT MUTATION 4 Change Mgmt

PROJECT MUTATION 4

Requirements Mgmt

Contract Mgmt


Project Development Process

Risk Mgmt

Project Tracking

PROJECT MUTATION 3


Project management mutational model for acquisition process of information systems.


PROJECT MUTATION 2



PROJECT MUTATION 1

Project1 Definition PROJECT MUTATION Stage


PROJECT START




Project Support - Maintenance

PROJECT MUTATION 5



PROJECT MUTATION 4


Information Technology project management mutational model.

Project Development Management

Project Acquisition Management

PROJECT MUTATION 3



PROJECT MUTATION 2



PROJECT MUTATION 1

Project Definition Stage


PROJECT START



Systems development and systems acquisition process mutation.

The project management mutation models apply the process agility and stage agility concept as well. Mutation is applied in the entire project making each project stage a different project that can possible need not only different processes or stages but different frameworks of methodologies as well. The concept of process and project mutations comes to incorporate all agile technologies and methods with all methodologies and process developed so far and used successfully per case. Despite the fact that project mutation models can contribute significantly to project management they do have an Achilles heel and that is the maturity required to determine the processes, stages, frameworks and project decomposition in order to predict and the project mutations


Evaluation and Selection of IT Solutions based on ...

Evaluation and Selection of IT Solutions based on ...

Suggest Documents

Selection and Evaluation of Test Data Based on Genetic Programming

Market segment evaluation and selection based on ...

An Empirically Based Selection and Evaluation ...

An Evaluation of Sampling on Filter-Based Feature Selection Methods

Portfolio selection based on graphs: Does it align with ...

Guidelines on Proposal Evaluation and Selection Procedures

selection. solutions. simplicity. eiko.com

A Study on Green IT Solutions - IJIRCCE

Merger and Acquisition Target Selection Based on

multiobjective ranking and selection based on hypervolume

Problems and solutions of accounting and evaluation

Adopting AHP Approach on Evaluation and Selection of Outsourcing ...

Classifier-based offline feature selection and evaluation for visual ...

Guidance on evaluation and selection of sustainable water demand ...

Entropy Based Test Point Evaluation and Selection Method for Analog

Intro: Off-The-Shelf IT Solutions - Decision Evaluation Ltd

Untitled - Arihant IT Solutions

Analysis and Evaluation of MapReduce Solutions on ... - BDEv - udc.es

Screener Evaluation and Selection - CASRA

Clustered Subset Selection and its Applications on IT Service Metrics

Research on Optimized Problem-solving Solutions: Selection of the ...

It Takes Three: Selection, Influence, and De-Selection ...

Evaluation of Atlas Selection Strategies for Atlas-Based Image ...

Selection and Evaluation of Reference Genes for