Resolving troubled agile development by applying mature project management--composite model of structural and process integration

Head of Project Management and Business Continuity Office, International Criminal Court

Abstract

This article presents concepts and approachs to solving problems in software development projects, experienced today by many business organizations. By providing an Agile Development case study, it reports on consolidation measures applied through a new Composite Model of Structural and Process Integration.

As the author of this work has spent years of his professional life attached to the information technology, software implementation projects and project management activities, this paper can be seen as an elaboration on coupling factors between experiences from empirical research and practices, project management standards and practices, and theoretical research in software project management, software development and related functional processes discomposure and analysis.

The presented model can contribute to making the business expectations more realistic, bearing in mind the fact that there is not a one-size-fits-all answer for all projects and all organizations. The author will further develop this model, by continuing its application in practice and by further academic research.

Introduction

Research on the implementation of software system projects shows disconcerting statistics; most software development projects are still challenged or even fail, and more than that, the progress is still not very evident.

According to Gartner’s research (2003), industrial success standard is 30%; according to the Conference Board Survey 40% of project failed (2001); according to a Robins-Gioia Survey 51% projects are unsuccessful (2001); according to Standish Group’s research [2001] (G. Stepanek, 2005), only 28% of software projects in 2000 succeeded completely, 23% were cancelled, and the remainder were substantially late (by 63% on average), over budget (by 45%), lacking features (by 33%), or, very often, all of those issues combined. According to CHAOS 2004 survey results (Standish Group, 2006) most software development projects are still challenged or even failed; more than that, the progress is still not very evident.

And consequently, why then are companies/organizations failing? The answer to that question is based on interviews with nearly 150 senior executives worldwide managing the average annual revenue of considered companies was about €3.5 billion (Deloitte Consulting LLP, 2006). The research shows that a major cause of process and resources sync misbalance with the overall organizational strategy lies in a proper definition of the benefit targets at the outset, and building these into the performance evaluation strategy.

The question still remains: what can we do now to support and enable better business processes? Or better project management competencies? The answer is that project management can help increase organizational agility and improve efficiency with a new operating and management focus based on enterprise-wide process and technology integration - business process fusion.

Objectives - what will readers take away from this article

The objective of this paper is to present the specific processes at the implementation of custom-built enterprise software with the aim of ascertaining structural and process factors which will, through the intervention cycle, leverage an implementation model contributing to a successful project outcome. The emphasis is on the mandated role of project management as a coherent instance providing guidelines, competencies, governance, strategies, methods and tools which contribute to the shift from disaster to project success.

This paper includes a real-life Agile development case study. The presented intervention cycle describes achieving business objectives through problem identification and definition, problem diagnosis, intervention design and elaboration on the formed solution – the Composite Model of Structural and Process Integration (CSPI).

The key postulates of the CSPI model are further analyzed including established Software Life Cycle Development (SLCD) model, exposing a structural framework of applied project methodology, as well as the evaluation of results and verification whether the objectives of the applied model achieved the implementation objectives.

Recommendations on further steps with the provision of techniques that readers can “take away” and use in their own business practice are enclosed at the conclusion of this article.

Research Framework

In their study C.P. Holland and B. Light (1999) concluded that five factors, directly influencing and challenging the implementation process and a project outcome, are interrelated and grouped as organizational and functional strategies, namely project management strategy, business process re-engineering strategy, IT strategy impacted by IT strategic review, thus all of them influenced by business pressures and IT and business legacies. Since the impact of a strategic context to the implementation of custom-built enterprise software is the essential organizational enabler, I relate to this functional strategic framework as theoretical backing, extending the influence of these factors into the implementation model, implying transformation and introducing new factors that will modify the framework in the way to address common elements applied at the implementation of custom-built software projects. Those factors are determining the overall structure and/or configuration of the whole composite model and should be shown separately.

The five strategic factors are used to quantify the influence on the implementation model as well as to establish which criteria are of greatest importance to the model construct and, on the other side, the impact on internal model integration and rollout resulting in project success.

The conjoint strategic factors influencing the implementation model are the following:

–    Project Management Strategy;

–    Integration Process Modeling (IPM) Strategy;

–    Business Legacy;

–    Business Pressures; and

–    IT Strategy.

Overview of conjoint strategic factors that affect the implementation model

Exhibit 1: Overview of conjoint strategic factors that affect the implementation model

Implementation Model: The objective was to establish a composite implementation model based on integration of the functional, development and life cycle meta models, and to determine the influence of factors and selection criteria included into the development of such a model. The case study analysis provides the drivers, attributes, key enablers and empirical background concepts emerging from the practitioner’s perspective. The appliance model provides a representation whether a sole, or a hybrid form of Software Life Cycle (SLC) methodologies, corrective and integration factors are suitable for the development of the composite model.

Project’s success: By determining the factors which resulted in the project success, it is safe to conclude that that a particular model results in a success and, therefore, should be used for the implementation of complex projects.

Having categorized all the selection criteria under their respective factors it is possible to conceptualize it into a conceptual Composite Model of Structural and Process Integration.

Theoretical Framework

Exhibit 2: Theoretical Framework

The drivers, attributes, key enablers and concepts for the development of an appropriate composite model of structural and process integration, applicable for the development and implementation of complex information systems, emerge from external (functional, organizational, managerial, and pressure factors) and the project’s internal factors (Software Life Cycle - SLC methodologies, integration and corrective factors).

The project management competencies cluster (PMI, 2002) and related skills play a critical role in the software development process (Futrell, Shafer, & Shafer, 2006), and it is the essential enabling, utilizing and integrative factor of the implementation project.

Business pressures, defined and grouped as globalization, deregulation, IT and competitive forces (Porter 1980; Moss-Kanter, 1989) together with legacy systems influence the implementation process, that is the enactment of the IT strategic review, project management strategy, Business Process Modelling (BPM) strategy (or BPR – Business Process Reengineering), and IT strategy.

External pressures affecting the implementation development effort at both strategic and tactical levels are in the diversity of stakeholders’ influences along with key factors in the business pressures. There are several pressures impacting on implementation: to develop and release a product quickly, not to hire more people, requirements change, specialization of the product, supporting the product in the field (B.P. Senese, 2002).

All these pressures increase the resolution of uncovered problems and result in managing multiple contingencies and costs, with the least amount of financial resource and get it into the hands of the customer with the pressure of an unchanged schedule.

Organizational maturity, as business legacy factor, depicts the organization’s capability in the integration of people, processes, technology, and measurements. This means that the higher the maturity level the higher the chances that an organization will be able to improve information integration and its quality, in addition it will allow projects to create solutions that would enhance chances for success and the organization’s competitive positioning.

IT legacy systems are usually not aligned with the business strategy due to a high level of fragmentation and disparity, having an increasingly inconsistent role in response to market changes and the simplification of the international accounting, commercial and manufacturing systems. IT legacy systems were supposed to facilitate the management of enterprise-wide functions, where we witness the increasing costs of making disparate software entities capable of cross-interfacing, integrating and exchanging data with other disparate business software within the organization, in order to comply with the strategic objectives. The systems are also confronted with compliance issues and increasing maintenance costs, owing to technical difficulties. Therefore, a lot of companies consider retiring their legacy systems, viewing them as an expense rather than a strategic opportunity.

The IPM emerged during the past few years, where a considerable effort on structuring enterprise architecture was made by the major BPM and software vendors in order to show how the applications could support business processes. The IPM integrates the functional BPM approach of a system discomposure into specific process levels (and jobs, tasks that needed to be performed) with the system architecture, translating and globalizing the functional discomposure into reusable business application patterns.

The synergy of IPM is in the fact that it interfaces the transformation of a functional process into its mirrored system representative, allowing controlled and instant end-to-end change management with embedded quality control within the whole considered process workflow. Therefore, the proliferation of a functional process change to the platform independent system process representative can be achieved impeccably, consequently allowing for smoother transition of business (functional) and application (systems) legacies.

The significance of applying the BPM is in process discomposure, streamlining processes at both the enterprise and the specific process levels, combining a process analysis and redesign with measurement and control strategies, including changes of an organizational (business) culture to focus more attention on processes and, especially, on continuous process improvement.

The BPM stands as the critical success factor for project implementation due to the fact that the chosen SLCM (Software Life Cycle Model) cannot be efficiently and effectively utilized at the key stages of requirements analysis and modelling without the existing functional processes being defined, mapped, verified, consolidated and approved by the organization. The structural clarity of a functional BPM will contribute to diminishing the risks of applying unsuitable SLCM, making the transition from functional blueprint into the functional design more accurate, which will result in a timelier product release, lower the project costs and a product more in line with the customer’s expectations.

Without being properly structured, harmonized and balanced, these factors will lead to an unsuccessful implementation and consequently disrupt related and dependable business processes. Who is accountable for that? The answer is: Project management facilitates corrective factors, and if done properly, then the relations and interactions between projects, business pressures and legacies are more balanced and lead to project success.

Project Management

“Methods, tools and technology interrelate in complex and constant ways and require the process in order to achieve balance. These three entities are at the heart of project management, software and quality” (Futrell et al, 2006). The quality of the software incorporates widely used FURPSS (Functionality, Usability, Reliability, Performance, Supportability and Security) factors.

The bodies of knowledge for project management, software engineering and software quality are recognized by several professional societies: PMI®, ISO, IEEE, SEI, ASQ™.

Software project management embodies three practices: software, project and management. Software is the program(s) that is (are) the product of a (software engineering) project (R.T. Futrell et al). Software standards and quality are defined by ISO, IEEE, SEI, ANSI and ASQ™. A project is a large or important undertaking that is planned. Management is the practice of executing and controlling the project. Project and project management standards, methodology and guidelines are defined by PMI®. Software engineering is a disciplined, systematic approach to the development, operation, maintenance and retirement of software through the practical application of scientific knowledge and processes (Futrell at al).

PMI® defines project management as “the application of knowledge, skills, tools and techniques to project activities to meet project activities” (PMBOK® Guide Third Edition, 2004, pg. 8) Practising project managers often say that project management is “getting the job done on time, within budget, and according to business partner requirements.” The standard for Project Manager Competency Development (PMCD) framework (PMI, 2002) was developed to be applied generically to all project management regardless of the nature, type, size or complexity of project, with the aim of improving the performance of project personnel and consequently, performance of projects, programs, organizations and profession.

Software Project Management adopted thirty-four competencies, organized into three categories: product, project and people (SQI BOK), required knowledge for every software project manager (Futrell at al).

Process models were originally proposed to bring order to software development. These conventional models have brought useful structure to software engineering work and have provided a reasonably effective roadmap for software teams, however software engineering work and the product that it produces remain on “the edge of chaos”(Pressman, 2005).

An SLCM is the framework for defining the repeatable process that the software engineer applies to the development of software. It defines the explicit practices that can be used to consistently produce high-quality software systems. The concept of the SLCM applies to all software projects, whether large or small (Futrell et al).

All the models have some sort of scoping, requirements gathering, designing, developing, testing, and implementation activities. The most life cycles are adaptations and combinations, and all software evolves. The importance of clearly demarking the transition from “developing” line to “implementing” line is in control and management (Futrell et al`).

The selection of SLC model depends on the specific project requirements and scope, and it is done based on an appropriate analysis.

Agile Process Models

Agile methods were conceived by various software developers in order to accommodate fast changing requirements and at the same time boost the operability, efficiency, and effectiveness of organizations. Agility in software development emphasizes quality in design. The Manifesto for Agile Software Development was signed in February 2001, where the significant importance of agile software methodologies was underpinned. The essence of Agile methods is to overcome perceived and actual weaknesses in conventional software engineering. Agility has become today’s buzzword when describing a modern software process; everyone is agile (Jacobsen, Booch & Rumbaugh,1999).

The main concern of Agile methodologies is the ability to embrace changes which are very likely to happen in environments which lack predictability. To achieve the objective, Agile methodologies use three key principles: a focus on adaptive methodologies, a focus on people, and a focus on self-adaptive processes.

Major representatives of Agile process models are Extreme Programming (XP), Adaptive Software Development (ASD), Dynamic System Development Method (DSDM), SCRUM, Crystal, Feature Driven Development (FDD), and Agile Modelling (AM).

DSDM method - selected SLCM for the implementation - provides a framework for building and maintaining systems within tight time constraints through the use of incremental prototyping in a controlled project environment (R.S. Pressman). DSDM suggests a philosophy that is borrowed from a modified version of Pareto principle, 80% rule: 80% of an application can be delivered in 20% of the time it would take to produce 100% of an application, i.e. a new increment starts after 80% of work is done in previous iteration. The method is maintained by the DSDM Consortium, a worldwide group of member companies who apply the method. The Consortium has defined an agile process model, DSDM life cycle, which defines three iterative cycles, preceded by two additional life cycle activities: Feasibility study, establishing the basic requirements and constraints with analysis whether the application to be built is viable for DSMD process; Business study, providing functional and information requirements that will provide value, with the basic system architecture; Functional model iteration, provides incremental prototypes, intended to evolve into the deliverable; Design and build iteration, reviews produced increments in accordance with quality standards; and Implementation, where operational prototypes are placed in productive environment. The DSDM method can be combined with XP or ASD concept.

Case Study – Agile Development Project

The case study covers the methodology framework from a perspective of an empirical, real-life custom-built software implementation project covering core business processes, illustrating how established assumptions have led to the problems that cause project to fail and what impact each of these assumptions had for the unsuccessful project outcome.

The second part of this case study presents solutions to these problems by applying the scenario described in Research Framework, the CSPI model, showing how the restructure and consolidation of a deeply troubled project succeeded by being managed differently and by utilizing depicted factors.

Requirements: A judicial organization required an electronic system for supporting its judicial functions in the areas of case management, management of in-court sessions, disclosure of case related information and collaboration with the parties. To satisfy these requirements, the judicial organization was to implement an Electronic Court System (e-Court) that includes the Case Management System (CMS). The CMS was required to be fully integrated into the organizational system landscape, in particular integrated with the organizational Electronic Document Management System (EDMS) for the registration/filing of documents and the association of metadata to those documents; administrative ERP system for the access and usage of human resources and budgetary/financial data; internal e-mail system for automatic generation of e-mail notifications from the system; In-Court system for the purpose of public disclosure of case related information; and the Active Directory for the user access and authentication purposes, as users will enter into the CMS via the internal local area network.

Based on implementation agreement, the project commenced in Q4/2004 with the objective to build and deliver a CMS based on requirements as recorded in the Request For Proposal (RFP) document, which includes the software product composed of 8 modules. Intended delivery date for testing was October, 2005.

Planning: The project plan defined the approach to the project, as well as the control and reporting process, including control and reporting standard and procedures (review and acceptance, change and document control procedures), risk and issue management, and status monitoring and reporting. Each working group lead, participating in the weekly project management team meeting, was appointed for submission of his/her progress report for the area of responsibility. At the weekly meeting the overall progress was planned to be discussed and actions defined based on notified deviations from the plan. The project manager’s responsibility was to compile a monthly progress report for the Steering Committee. The project management role was split between the implementation vendor and internal organization. The internal project manager takes prime responsibility for implementation and delivery of the product, on time and within budget, and in accordance with the functional and technical specifications as described in the project scope. The vendor’s project manager was responsible for the delivery of the system as agreed in the contract between the two parties, and for managing its team of software architects, system analysts and developers. The user organization, composed of internal staff members, was divided into three subgroups: Business Focal Point, ICT Focal Point, and User Representatives Focal Point.

The quality management plan was determined through quality procedures for document control, review and acceptance. Reviews were to be carried out for each deliverable (documentation and software) by a walkthrough method (individual or group), where the reviewer(s) step through a deliverable to check for errors, inconsistencies, incompleteness, etc. The findings and actions of the walkthrough were to be documented. Walkthroughs were used to review the use cases as well.

Physical resources for the project included software and development tools, operating and other system software, and software tools for recording and tracking use cases and issues.

Design and Build: The SLCM for the project was the vendor’s internally adopted method CDM (Custom Development Method) FastTrack, a DSDM compliant method which is originally based upon Rapid Application Development approach that incorporates time-boxing, prioritization, iterative development and incremental delivery to get fit-for-purpose applications that deliver business value at the earliest possible moment. DSDM utilizes continuous user involvement in an iterative development and incremental approach, which is responsive to changing requirements, to develop a software system that satisfies the business requirements on time and on budget. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

The key concepts were:

–    Incremental development with prototyping (or DSDM);

–    Usage of Use Cases, screen layouts and process flows to document, visualize and discuss analyzed requirements and functional system design;

–    Time-boxing, and

–    Prioritization of requirements.

The development process followed three steps per application module, repeated per module as follows:

–    Requirements analysis: The solution concept of the module was to be created through a maximum of three workshops with key users and with the requirements information from the RFP. At the end of the second workshop, priorities were defined for the subjects of the third workshop. Subjects/functionality which couldn’t be sufficiently defined in the three workshops were not implemented in the project, but parked for a subsequent release. The solution concept comprised the scope of the module and the nature of the solution, recorded as a list of use case descriptions with supporting use case diagrams and process flows. The customer was to be asked to confirm the correctness of the solution concept (requirements signoff).

–    Detailed analysis, design and build: Continuing from the requirements analysis and with the use of workshops, the use cases have been detailed into use case steps. Each function was then visualized using a screen/report mock-up layout. These were presented to and discussed with the key users. The customer was to be asked to confirm the correctness of the functions (functional design signoff). After that, the development team proceeded with detailed design and build of all the functions.

–    Test and refinement: All functions were integrated into a working module and integrated into the already working modules. This represented a new release and has been deployed into the test environment. At that point, the module was still not complete; several functional aspects were not implemented yet or not known. The customer was informed of these aspects on a weekly basis and asked to test the release and thus verify the correctness of the delivered solution. This was formalized with the acceptance signoff. During the testing process, key users fed back issues and remarks to the development team. Depending on the priority of the remarks and the available budget, the functions have been refined and delivered for re-test. Here, a priority mechanism called ‘MoSCoW’ (Must Have, Should Have, Could Have, Won’t Have) was applied. Parallel to this process, the user documentation was also to be developed, refined and completed.

Deliverables: The first phase of the project (one module and basic EDMS integration) was delivered for the acceptance tests in March, 2005. The integration solution was hard programmed via the API layer, allowing only unidirectional data flow from the host application to the EDMS system. Further limitation was in the fact that the EDMS solution required creation of metadata based on certain rules, and in order to comply with these rules it was clear that an extensive programming is required in the future.

That was the point at which the organization engaged a 3rd party QC/QA instance and EDMS vendor in order to resolve this issue, especially for the second phase of the project, to comply with the development standards and prove the quality of coding.

In December 2004 the organization engaged one full time external project manager for professional services of managing the project in 2005. The vendor’s project manager was discontinued as of March 2005 and as of that point in time the vendor’s project management consisted of efforts done by the commercial manager and one of the team members. At the end of July, 2005 the vendor appointed another project manager. The progress report of July 2005 showed that the project was far behind the schedule. The situation was reported mid August 2005. The following happened in reality: due to a lack of scope control, far more rework/extra work was accounted on modules than planned. This was not anticipated by the implementation partner. Effects: go-live date planned for mid January 2006 was not met, budget was overspent. After the situation was escalated, the Functional Point Analysis (FPA) of the scope of work was done with the aim of computing the size and complexity of the system based on a number of computable characteristics. Based on FPA, a new version of the project plan was created. The plan was not formally agreed. However, it was already apparent that all 8 modules could not possibly be delivered in due time. The result of the scope exercise was delivered to the implementation vendor. The conclusion was largely that the requirements were not prioritized, virtually all modules were in scope for March 2006, thus: impossible to do.

The above mentioned reasons, combined with the fact that both the implementation partners could not agree on new contract terms before 2006, have led to the situation where the implementation vendor has suspended all project work and left the project as of beginning of January, 2006.

Failure Analysis

In their debrief letter, the vendor stated that the project delay and failure was caused by the reasons that fall in the following categories:

–    Assessment of the project scope;

–    Use of system development process;

–    Project management approach;

–    Technical issues.

Analyzing the project documentation, a recurring thread in the project group minutes was that the vendor raised the issue of insufficient commitment of the organization personnel in the requirements and test activities. At the same time, representatives of the internal organization raised the issue that the vendor team was not visible and didn’t involve internal personnel enough.

In general, a substantial increase in project duration was caused by a large increase in scope and/or an incorrect estimation. Increase in scope must lead to change management actions by project management. Then controlled changes can be made in budget, duration (time), schedule (resources) or outcome (quality / MoSCoW / prioritizing of functionality) of the project. However, the results from the scope analysis confirmed that the major reason for continuous scope change and resulting disputes were primarily in indistinguishable processes and, hence, in a lack of functional process knowledge on the part of both implementation parties, as a prerequisite for in-depth functional analysis and system modelling.

As no system is built perfectly in the first try (the Pareto-principle of 80/20 rule used by DSDM model), in the process of system development 80% of the business benefit comes from 20% of the system requirements, and therefore DSDM (or CDM FastTrack) started implementing this first 20% of the system requirements to meet 80% of the business needs. This is good enough as long as the users are involved in the development process and in a position to ensure that the missing 20% would not cause any serious business consequences. That risk was neither anticipated nor mitigated nor avoided during the implementation.

Implementing the entire requirements often causes the project to go over deadline and budget, therefore it is unnecessary most of the time to construct the perfect solution, but the solution must include and cover processes defined and agreed by the project scope. It is critical to detect re-use possibilities and prevent substantial rework to earlier modules when work progresses to the next modules. The data model and use cases are input to plan the sequence of new iterations or time boxes.

It was clear that the failure was owing to the fact that the SLCM was not chosen, but imposed on the project by the vendor. Clearly, such a hard and difficult project is not suited well for the chosen SLCM due to the fact that CDM FastTrack (or DSDM) cannot work if the requirement modelling is not done thoroughly, and if neither user nor developer work together, sharing a workplace and communicating tightly and in a timely manner.

Thus, a proactive methodology ‘coach’ should have been introduced into the project to prevent incorrect execution of the time boxing approach; the overview of the complete system (data model and use case model) ought to be documented and the use of UML should have been introduced with low ceremony. The use case model and data model are needed to determine the fundamentals of the system; adding a User Interface Model (screen mock-ups or prototype modelling) should have been considered, because only having use cases makes it hard for the users to determine if the requirements are captured correctly.

Decision on continuing usage of the tool for capturing use cases and test cases/scenarios was an ongoing issue, because most stakeholders considered it not useful, and hard to communicate to the overall project user representatives if the content is correct. A lot of project time was spent on discussions about introducing a new tool, still having clearly in mind that whatever new tool is chosen it must not delay progress. Eventually, it became clear that not providing proper training for the tool was a project management mistake, and that the tool shouldn’t be blamed if something else is wrong.

The CMS project can be characterized as: business critical; business pressured (scope, integration, legacies timeliness, budget); with high level of customer intimacy (inadequate stakeholders management); with unclear requirements; using incremental development, and with the complexity of technical interfaces.

From the vendor’s point of view, all the above characteristics indicate a high-risk project profile. It should have been clear to the vendor that a different approach to the project management should have been applied in order to handle a project with such a profile. The vendor eventually performed a project health check, but the results were not communicated to the customer.

It was obvious that the project plan must contain an overall project plan (focus on phases of the project) and an iteration plan (focus on increments). Combined with the use case model and data model, should have lead to an early insight in reuse possibilities and overlaps between iterations. Also, a Software Architecture Document (SAD) should have been made for the project, a risk list maintained including project (management), functional, and technical risks. The use of time boxes at the second phase should have been clearly defined, which would determine the scope of the time box and consequently would have a positive impact on time, budget and quality. Furthermore, the staffing was an issue: at the requirements modelling stage, staffing should have been present to perform requirements capture, and the focus should have been shifted from development towards functional and technical staffing. At the system design and generation stage, more developers and test engineers should have been involved.

Consequently, technical issues originating from inadequate requirements modelling, adding contingency to the overall project, have to be solved properly. It was clear that a new approach to the project should be applied.

The used Agile SLC model (DSDM or CDM FastTrack) failed due to the following:

–    Requirements not clearly defined, prioritized or approved;

–    Development steps not completed sufficiently in order to trigger correct iterations, where Pareto-rule was never achieved, and therefore not applicable;

–    Proper decomposition never done, therefore iterative and incremental properties not enabled and therefore time boxing not accurate;

–    Project team was never empowered;

–    Extensive tests and validation never done – and not suitable for the model;

–    Legacies, integration activities and related pressures underestimated and not planned properly.

The factors leading to the project’s disruption and failure can be divided into three major groups: unclear processes, project management approach and inadequate system development process, as shown below:

Causes of Project Failure

Exhibit 3: Causes of Project Failure

Consolidation

It was a must for the organization to consolidate the whole project in order to achieve planned strategic objectives. In order to do so, the organization appointed a new (internal) project manager. The approach in project restructure was as follows:

–    Analysis and evaluation of the previous implementation cycle including internal QA and risk response analysis, was done by the appointed project management;

–    Analysis of the project product, software code quality and compliance with the standards was done by external QC party;

–    The resulting report included the current project status, achieved deliverables vs. planned objectives, proposals on corrective actions, risks with mitigation measures and recommendations on how to organize the project in order to achieve successful closure;

–    The recommendations were presented to the key stakeholders in January 2006 and the approval for the project consolidation measures was granted.

There were certain constraints for the consolidation: the funds for the second project phase were already committed to the existing vendor, and in accordance with the organizational rules and regulations it was impossible reassign the funds to another implementation partner. The choice was obvious: either lose appropriated money, or change the vendor’s approach, organization, methodology and methods applied to the project and finalize it accordingly. Another related constraint was legacy in time and material contracting with the vendor, because often changes in scope generated uncontrolled change management process, where the organization ascertained surprises in increased tangible costs. The third constraint was the reported status on the completion of modules done by the vendor, due to the fact that the tests were not validated nor accepted by the organization.

Besides the facts elaborated above, it was clear that the consolidation required a proper project management approach, efficient functional and integration BPM, effectual dealing with the business pressures and IT legacies and life cycle processes incorporated into the model.

Consolidation measures included:

–    Applied project management standards and methodology;

–    Defined, fixed and approved scope of work;

–    Defined implementation SLCM;

–    Project reorganized into Program level; Program Charter created and approved;

–    Finalized and approved contract (addendum) with the vendor; Program Charter incorporated into the contract;

–    Project structure reorganized;

–    Objectives/Deliverables/Roles/Responsibilities defined and applied;

–    Definition of the core functional and integration processes to follow the BPM/IPM methods;

–    Created, integrated and approved Blueprint document to include the results from BPM/IPM (re)engineering and software functional designs;

–    Test cycles (functional, performance, stress, regression, security, integration, acceptance) applied all the way through the project life cycle by internal and external instance; validated and approved by the internal organization;

–    Monitor and control system defined;

–    Life cycle processes applied.

The key program issues are governance, stakeholder management and achieving benefits. Governance includes establishing approaches towards organizational values, structure and leadership. In order to enable and apply efficient and effective program governance, the program manager requires clear acknowledgment of organizational strategies, policies, systems and processes, as well as an analysis of major stakeholders, an appraisal of their influence and continuous monitoring of changes in their area. Achieving benefits is primarily the program manager’s focus, as being the result enabler.

Based on the project reorganization into the Program level, the ownership shifted completely to the organization, positioning the implementation partner co-responsible only for the first project within the Program: implementation of the core CMS functionality resulting from executed BPM/IPM/BBP processes, system landscape architecture (software functional design) and coding. The functional design, when delivered, was a part of an integrated BBP document.

The BPM/Business Blueprint (BBP) area was strengthened with 3rd party consultants, experts in functional business processes. They also performed the role of internal QC/QA instance by doing the functional A&I (Acceptance and Integration) tests and reporting on functional compliance of the product.

At the area of IPM (integration with the overall ICT infrastructure, including EDMS and ERP systems, email system and the Active Directory) the team was strengthened with external experts and respective internal ICT infrastructure staff.

The monitoring and control process was strengthened with 3rd party QA instance for the wide range of security, performance, stress and load A&I tests of the product, as well as inspection and compliance of the delivered code quality.

The consolidated project structure was set in order to address the project’s CSFs. The project organization was restructured twice, in 2006 and 2007. The 2006 organization was addressing the project healing state with the aim of achieving the consolidated, validated and approved baseline deliverable(s). The 2007 organization was set to comply with already consolidated project, with the aim of achieving an accelerated delivery cycle for the organization. By simplification of the project structure the focus was then shifted onto develop-test-correct-deploy cycles.

The Key Stakeholders accepted and signed off the reported project deliverables and further improvement recommendations, including the further Program strategy.

CSPI Model

As the agility of CDM FastTrack (or DSDM) SLCM did not bring results; on the contrary, the project went into a disastrous situation and it was clear to the project management that the certain changes must be applied, as follows:

–    Strengthen the project management framework in order to ensure proper project governance and controllability, ensure that the business pressures and legacies are considered and enabled properly, keep the key stakeholders proactive and decisive throughout the project life-cycle, and make the implementing organization responsive and adoptive for the change.

–    Reorganize the project into the program level and the implementation of each project that resides within the program to follow the standards for program and project management and PMBOK® project methodology;

–    Deploy a new SLCM.

The project implementation cycle followed the process groups mapped to the PDCA cycle {Initiate / Plan / Execute / Monitor & Control / Close}, so the project SLCM was changed to composite stages, as follows:

Initiate Conception
Plan Integration Iteration
Execute Immaculation Iteration
Monitor Reproduction Iteration
& Control Close Evolution Iteration
Description of the composite SLCM stages

Exhibit 4: Description of the composite SLCM stages

The applied composite SLCM is envisioned as staged, iterative and incremental with controlled agility, as shown in below in Exhibit 5:

Composite Model of Structural and Process Integration

Exhibit 5: Composite Model of Structural and Process Integration

The conceptual mapping of the CSPI model is shown in Exhibit 6:

CSPI Model Conceptual Mapping

Exhibit 6: CSPI Model Conceptual Mapping

Conclusion

The CSPI model’s life cycle stages conceptually address and map the factors and activities required for successful engaging and delivering of organizations’ projects and programs. As nowadays the types of project considered in this work are very complex endeavours with the critical impact on business strategies and objectives, it is imperative for the businesses to consider a proper appliance of all the relevant factors which will contribute to a successful implementation and post-implementation life cycle.

The applied CSPI model and its embedded SLCM is envisioned as staged, iterative and incremental with controlled agility; it considers and emphasizes the role of applied project management standard and methodology as the originating guideline. It emphasizes customer involvement and promotes team work; it thus has structured comprehensive and understandable rules and practices. It stresses the quality of deliverables, sets the strategies on how to embed deliverables into the organizational landscapes and to process their life cycles. It enables achieving values to the organization by meeting the expectations on delivered product(s) and services(s) and promotes result-based work.

Notwithstanding a decision making process on what SLC framework will be chosen by an organization, by way of conclusion I would recommend the following:

–    Apply the full cycle of functional Business Processes Modelling and Integration Process Modelling prior to implementing a core, organization-wide software project;

–    Keep standards at the high value, methodologies governable, methods adoptable and quality persistent through proactive project management competencies;

–    Participate proactively with the chosen vendor in an analysis and decision-making process on what software life cycle will be applied to your project;

–    Work steadily towards enabling a project-based culture and organization in your company.

References

Agile Data (2009) Agile Modelling, Retrieved on February 2, 2008 from www.agiledata.org;

Boehm, B. & Ross, R. (1989) Theory W Software Project Management: Principles and Examples, Piscataway, NJ, USA: IEEE Press.

Deloitte Consulting LLP (2006) Adopting the Value Habit (and Unleashing More Value for Your Stakeholders), New York, N.Y., USA: Deloitte Consulting

Dennis, A., Haley-Wixom, B., Tegarden, D. (2005) Systems Analysis and Design with UML Version 2.0 - An Object Oriented Approach, Second Edition, Hoboken, NJ: John Wiley & Sons, Inc.

DSDM Consortium (No Date) Dynamic Systems Development Method (DSDM), Retrieved on February 3, 2008 from www.dsdm.org;

Futrell, R. T., Shafer, D. F., Shafer, Linda I. (2006) Quality Software Project Management, Upper Saddle River, NJ: Prentice Hall PTR.

Gartner, (no date), Retrieved on March 3, 2008 from http://www.gartner.com;

Holland, C. P. and Light, B. (1999) A Critical Success Factors Model for ERP Implementation, IEEE Software, 16(3), 30–36;

Jacobsen, I., Booch, I.G., & Rumbaugh, J. (1999) The Unified Software Development Process, Reading MA: Addison-Wesley;

Larman, C.g (2002) Applying UML and Patterns, An Introduction to Object-Oriented Analysis and Design and the Unified Process, 2nd ed., Upper Saddle River, NJ: Prentice Hall PTR;

Lesnevsky, A.S. (2007) Enriching PMBOK Guide by practices and techniques of Agile project management of software development, PMI Global Congress Proceedings, Budapest, Hungary;

Manifesto for Agile Software Development (2001), Retrieved on March 6, 2008 from http://agilemanifesto.org;

Masticola, S. P. (2007) A Simple Estimate of the Cost of Software Project Failures and the Breakeven Effectiveness of Project Risk Management, 29th International Conference on Software Engineering Workshops(ICSEW‘07) IEEE, CHAOS 2004 survey results, 1-1

Moss-Kanter, R. (1989) When Giants Learn To Dance, New York: NY: Touchstone.

Pressman, R. S. (2005) Software Engineering: A Practitioner’s Approach, 6th ed., Columbus, OH: McGraw-Hill Professional;

PMI (2006) The Standard for Program Management, Newtown Square, Pennsylvania, USA: Project Management Institute.

PMI (2004) A Guide to the Project Body of Knowledge (PMBOK® Guide), Third Edition, Newtown Square, Pennsylvania, USA: Project Management Institute.

PMI (2002) Project Manager Competency Development (PMCD) Framework, Newtown Square, Pennsylvania, USA: Project Management Institute.

Senese, B. P. (2002) Managing Successful High-Tech Product Introduction, Norwood, MA: Artech House Publishers;

Stepanek, G. (2005) Software Project Secrets: Why Software Projects Fail, New York, NY: Apress.

Thiry, M. (2007) Delivering Business Strategies through Project, Programs, Portfolios and PMOs, Valense Ltd.;

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2010, Goran Banjanin
Originally published as a part of 2010 PMI Global Congress Proceedings – Milan Italy

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.