Category: Project Management

Systems Thinking: Part 1
Common sense tells us different problems need different solutions, having a “systematic” way of evaluating new problems can help us avoid relying too fully on our assumptions and default response. Use this introduction to systems thinking to evaluate where your problems generally land on the Cynefin Model.
Systems Thinking Part One – YouTube
Using Project Management Disciplines to Improve Performance
I was asked late last year to write a white paper for Axelos on some of the reasons organizations might consider using disciplines from the PMBOK, from PRINCE2, and from Agile practices like Scrum to help them improve their project performance. It also became a nice opportunity to demystify some of the mistaken notions about each set of practices. Short summary: they work and play together very well, but require some organizational discipline, and should be adapted to meet the needs of any particular organizations.
Here is a link to the paper…I hope you enjoy it, and reach out to me if you have questions on how you might leverage these practices to help your organization improve its performance.
Best,
Patrick
PRINCE 2 US Launch Podcast
I had a nice opportunity to take part in a recent Axelos podcast as part of their announcement of the new Managing Effective Projects with PRINCE2 US version. Take a listen; for those of you who aren’t familiar with PRINCE2, it builds on a knowledge framework like the PMBOK by providing a tailorable methodology for project planning, execution, and monitoring. Whether your projects are more prescriptive or more Agile, using PRINCE2 will dramatically improve the quality and consistency of your team’s projects.
https://bit.ly/3kyaIuY
PM and ITIL
I have been thinking about Carol’s and IT Skeptic’s comments about PM (and have read the thread he pointed me to, and an awful lot more) and I still think this comes down to a simpler notion. We have a yawning, enormous gap in most IT organizations between Design and Operations, in many cases cast in stone through outsourcing deals to different entities with no aligned targets or shared accountability. This creates the hot potato issue with which so many of us are familiar, and which really drives my interest in service transition, and particularly in placing Early Life Support (ELS) firmly in the hands of Release and Deployment Management. It is in fact the job of PM to manage the SUCCESSFUL transition of their project deliverables (which we’ll assume to be a new or changed service) into the live environment, and to support it until
1) The service is accepted by the customer AND
2) The service is meeting its designated service levels (this implies successful event mgmt, operational monitoring and reporting, and other operational readiness capabilities that really should be flushed out more as part of testing and validation activities).
Project Management (and Software Development Lifecycle Mgmt, but that’s another article) need to be able to coordinate service design and transition activities, and I would liken it to the approach ITIL takes with functions. PM necessarily coordinates across all the activities in service design and transition…based on the scope of their project. Process team leads perform activities across multiple projects in support of process goals and objectives (which should map to project goals around, for example, functional and non-functional (or warranty!) requirements).
The actual ITIL books don’t in fact describe exactly how to run projects (and rightfully leave this for the complementary guidance), but like a similar discussion currently on one of the LinkedIn threads about how ITIL leaves appropriate space for governance models (can anyone say CObIT), it really does so for PM as well, leaving flexibility needed to encompass large programs and small projects alike, while still providing a core set of building blocks needed to build a good service.
I’d like to hear from all of you…where do you see the big gaps, and what are your recommendations for addressing them? If you were writing ITIL 4.0, what would you add/remove/change to improve the efficacy of the guidance?