This is a guest post by Pradeep Bhanot. Pradeep is the Product Marketing Director for IT Governance solutions for EMEA at CA. He is based in England after a 16 year spell in California’s Silicon Valley. Bhanot is a U.S. patent holder and earned a bachelor's degree in Computer Science from Greenwich University.
My work in change management has taught me that change is inevitable and should be embraced, not feared. Project management needs the formality of traditional methods to satisfy the need for rigor, auditability, accountability and control. Project management practices encourage project reviews after the project is live to gather learnings that the PMO can use to refine and institutionalize good practices in future projects. Changes within a project that impact scope, schedule and cost, are usually treated as negative exceptions.
Project management can take a leaf out of the software development world, which parallels PPM by implementing a formal Software Development Life Cycle (SDLC) process to ensure quality and accountability, but has been far more open to make change management the norm and channel it into a constructive force.
Decades ago, when I first started programming, I would first create a shell using a boilerplate for the main program and exception handling. I would then outline all the required functions that would need to be called. This parallels the outline of a project plan that forms the natural sync or review points or gates. Next, I would add all the comments describing the main body and functions, which would ease maintenance, QA and provide the basis for demonstrating adherence to the requirements document (if any). Changes to requirements would also be documented in the comments. Today, these would also be captured in an integrated or external requirements system. In the case of CA Clarity PPM, the requirements planning feature is part of the project management function. These high level specifications form the basis of the design and can be used by QA, project management and documentation writers to gain a common view of the intended functionality.
The interesting part for me was coding the functions taking a stepwise-refinement approach (similar to the Kaizen or “continuous refinement” element in Lean approaches that encourage “change for good”). This is similar to today’s iterative methods, such as Agile approaches that enable the work to be scaled up to tight development teams to harness the energy of many eyes and brains to build a quality deliverable in a short space of time.
The cultural change project management is going through now is making change management a norm, rather than an exception, and adopting agile approaches to improve planning for the fast execution of sub-projects, while maintain quality and ensuring customer acceptance. This recognizes that requirements change and fosters closer collaboration between the build team and the customer as they refine requirements and the shape the deliverables together.
The result is rapid delivery of projects that meet the sponsor’s requirements, increasing success rates.
(images by mshades)
Twitter -
Subscribe -
Newsletter -
Bookmarks
Latest, greatest and favoritest posts:
The Three Types of Change
Creativity as the Root of Software Development
Change is the Only Constant
