Customer Centric Project Management


Engaging stakeholders is not just to manage changes to requirements

Charles Villanyi Bokor

The CERP Group

Ottawa, CANADA


Customer Centric Project Management (CCPM) is defined as the continuous re-examination, evolution and integration of organizational strategy, desired outcomes, stakeholders’ vital needs and expectations, business processes, and project development methodology, into the enabling technology project’s mandate and deliverables. It is to produce deliverables/outputs that are fit for the purpose and can be leveraged to achieving the intended outcome.

CCPM is based on empirical observations and current literature on project management and requirements change management, as well as on limited trials and test. When approved by executives, CCPM engages stakeholders to define the outcome and continuously during the project development lifecycle, enhance the vital requirements that define the output to be produced. It is often viewed by IT as involving ‘them’ in what ‘we’ do. CCPM focuses less on how we meet estimated schedules or costs and more on what are the vital outputs so corporations can create business value. It is not new, but this return to the obvious requires a cultural shift, and holds the involved senior executives, system owners, business analysts and the project manager, accountable.

Key Words: project development, customer centric, business requirements, requirements definition process, project management, requirements change management, project development team, outcome, methodology, value, accountability, project failure.


In a recent article on the “10 common causes of IT project failure” [Carlson, 2013] one of the causes was: “Letting users delay projects by constantly requesting tweaks”. According to this cited cause of project failure and common belief, allowing business requirements to be changed post system design (that is based on the requirements) and during project development, i.e. allowing tweaks, may force the designed and partially developed project to be reworked, delaying the project and or adding costs that were not budgeted. A 1996 article [McConnell. 1996] noted that: “Studies have found that reworking defective requirements, design, and code typically consumes 40 to 50 percent of the total cost of software development (Jones 1986).”. Such significant variance between the pre-design estimated and the eventual cost of delivery or time to deliver, can in turn fail and have failed IT projects. Thus according to this school of thought changes to requirements should be limited to minimize changes to schedules and costs.

Limiting customer requested ‘tweaks’ or changes to the requirements is considering the changes to be less important than the originally stated requirements. It implies that the customer was not aware that the requested changes can be postponed. Not easily allowing changes to requirements implies that the customers who presented the original requirements and the Business Analysts (BA) who elaborated them and consequently defined the project’s output, knew the right or best business solution with which to create the expected business value or outcome, which is the original (not new) and the future definition of project success. It implies that they have expressed all vital customer business needs and expectations at the time the requirements were gathered and defined. It further implies that since the time the requirements were defined no one has learned or identified a better way to solve the business problem. In other words, due to an organizational flaw that prevents the organization from innovating or naivety there has not been any learning during the development of the project. By keeping the list of requirements static, the organization implicitly declares, that those who can prevent the additional effort to develop the changes or tweaks or act on opportunities to improve needed capability to be made, can decide on the eventual business results. By not making changes the mandated functionality is delivered over the significantly higher cost of an enhanced system indicating that being on-time, on-schedule and / or within budget is the organization’s priority.

People still exist who believe that a project should and could get all user requirements documented [waterfall concept] before project design and development. Some people still believe that people, organizations or project teams can if they try, involve the client/customer business experts and produce the list of requirements that does not need any further changes.

IT spending in Canada is in the neighborhood of $270 billion per year based on it being $2.68 trillion in the US [NY Times, 2013]. The annual cost of IT project failures is $1.2 trillion in the US and $6.2 globally [Sessions, 2009]. As a generalization, the lifetime cost of an application is about 6.7 times [Outsystems] its initial development cost and some or most of this cost is to fund what many in the profession term “PHASE II”, which is the ensuing phase to develop the needed requirements that were not delivered in Phase I. We know and now must practice how to develop projects that deliver the right functionality for a fraction of the cost we spend on them today.


To read entire paper, click here


Editor’s note: Second Editions are previously published papers that have continued relevance in today’s project management world, or which were originally published in conference proceedings or in a language other than English.  Original publication acknowledged; authors retain copyright.  This paper was originally presented at the 3rd annual University of Maryland Project Management Symposium in College Park, Maryland, USA in May 2016.  It is republished here with the permission of the authors and conference organizers.



About the Author

Charles Bokor

Ottawa, Canada


Charles Villanyi Bokor
is a Strategic Management Consultant focused on Leading to Better Decisions. Principal activities include Business Transformation, Problem Project Recovery & Leadership, Strategic Planning. Charles works mostly in Ottawa but has successfully completed assignments in Florida, Wales, Malaysia, Sweden and Australia, and was key-note speaker in Johannesburg South Africa and Victoria BC. Formal education includes an Executive Development and Diploma in Management (McGill University), M.Sc. Mathematics (Université de Grenoble, and U. de Montréal) and B. Sc. Mathematics (Concordia University). He was: Program Director of the Corporate Performance Management Program, Sprott, Carleton; Director of IS/IM at Royal Trust; and at Northern Telecom; CMC; CMC Board Member; PMI-OVOC Board Member; Governor of ICCC; is ITIL Certified and a TBS Independent Project Reviewer. Email: [email protected]