Customer Centric Project Management


By 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.


To read entire paper, click here



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]