There are a number of different approaches to delivering change initiatives available these days. Some suit changes happening in an Operational/BAU environment and others suit the Project Environment. Many use the same framework, just different labels, and sometimes also with a varying perspective. However, some of the techniques are the same, but what is important is the different way these techniques are employed, which I will explain later in this article.
In a Project Environment, there are only two established and recognised methods (approaches) in reality, and these are:
PRINCE2 (now 2017 version)
AgilePM
[Note here that I am completely open-minded (agnostic if that is a better word for) when it comes to various approaches, and that point is the main message in this article.]
I am concentrating on these two environments because it is in these areas and using these approaches where the “work is done”.
There is an article that looks at the vertical view from the “engine room” builds up to Portfolio level, which explains the different viewpoints. All the elements for the initiatives’ objectives that are developed/built are managed/controlled at Project/Scrum level. In a project environment, if there is a more strategic/transformational change, then we have Programmes that manage a number of projects that collectively contribute to that change.
In an Operational/BAU environment, there are a few others:
- Scrum
- Lean
- Xtreme programming
- SAFe
- LeSS
- DevOps (which from my understanding is not really an approach on its own, but an extension/enhancement of ALL the above!)
So which one should I choose?
What are the choices – the Macro element
This is not really the right question! It is NOT a case of which one! It is about understanding what the approach, or approaches, that the project needs to ensure it runs successfully!
I am concentrating on the Project-based changes here. It is hopefully evident that changes initiatives in an Operational environment usually employ one of the various approaches that are available as per the list above, generally speaking. There are differences in levels of work that each approach supports.
For example, Scrum will typically develop a series of products/features, as will LEAN, though as a continuous improvement cycle, whereas Xtreme Programming has just a small number of people, 2 - 4, working on just a couple of features such as fixing up a security leak or a bug-fix, in a very short timeframe.
Projects go through a series of Phases (as discussed/explained in another article) and this is where we come to the discussion as to which approach(es) – or “Hybrids”! Hence the two main methodologies, PRINCE2 and AgilePM. They both have Life-Cycles, defined Roles and Responsibilities (The project team), Documents (referred to as Products – just to confuse things) and various techniques and tools, which I will be writing about in the next section. In reality, is there really much difference between them?
It is more about which approach(es) should be employed for a specific time frame. This timeframe would be a whole phase, a stage/increment, a particular timebox or work package or even a smaller timeframe within the latter two.
What are the choices – the Micro element
In a project, there are a couple of levels of techniques and tools related to various approaches. In reality, none belong to any specific approach, it just seems that way.
One of the most important and useful technique is Prioritization. The most well-known and well-employed of many is MoSCoW. This technique for prioritizing is the best, and not only that, should be used for EVERY initiative. In a project, the focus is on the products and features that are required to ensure that the business benefit is achieved/realized and at the same time provides an understanding as to what there is for contingency. In other uses, it provides a timing perspective.
There are numerous other ways to Prioritize, numerically, size, importance (rather subjective as depends on whose perspective) and value, to name a few, however, MoSCoW is the best. It is assumed that it is mainly owned by “Agile”! Well, not true, it is also in the PRINCE2 manual and has been for several versions now!
Where Prioritization provides us with a mechanism to ensure we are building the right products/features to realize the Business Benefit, we also need to ensure that these products/features are also built “the right way”, meaning that they work and do what the business needs them to do. By taking an Iterative Approach (in this case at the build level), the teams can hone in on the right format, with Business involvement (a MUST), as they do so. As noted before, do NOT make the error of labeling this as “Trial and Error”, even if it looks like it. The team will have a pretty good idea of what needs to be developed and how it will function. It is also good practice to develop prototypes before-hand to check the understanding, where practical.
This is building the same feature, progressively, and checking with the business as they do so ensuring that the feature is taking on the form the business need/expect/anticipate to work the way they need it. If any changes are needed, then these can be planned and actioned whilst still in the build mode for that product/feature in a subsequent iteration. This ensures that when completed the business are also in agreement and ready to sign-off – business acceptance!
There are numerous formats of the Iterative Approach, Deming’s Plan-Do-Check-Act (PDCA) is the more well-known format, and variations on that as well. AgilePM has its own in a 3-step cycle rather than 4.
This set of development work usually, (normally a sensible approach), requires a form of time control. Timeboxing is the most commonly used technique, where time is a constraint, as it is in most situations (not all!), and even if not a constraint, good practice. More evident where it is realised that Scope is a more realistic form of Contingency (another topic!). In situations where there is a need for the build to be completed fully, a Work Package, (WP - definition is that this has a variable time frame to ensure the build is complete), should be employed. There are other ways to control this WP and its variable time frame from impacting on the project time frame as a whole. These two, Timeboxes and Work Packages can co-exist in the same time frame – Stage/Increment!
Once the build of either individual products/features, or a section of the final object, has been completed and signed-off by all parties, it/they could be ready for deployment within the project timeline. If relevant and realistic to do so, and the business and, in particular, Operations/BAU/External Customer, (area where this over initiative is being transitioned into), have agreed and are ready, (good change management needs to be engaged here!), then the real “benefit” is that business is seeing action and more importantly, are able to evaluate the deployment in terms of function and benefit. This is also taking an Iterative Approach, this time at the project level. Incremental building. And what is even more advantageous here is, like at the build level, if changes are needed because it’s not quite what the business expected, not functioning with respect to the realisation of the benefit, then changes can be made – while still within the project timeline. This is imperative. Too late when delivering right at the end.
It is understood that not all initiatives can deploy during the project timeline, however, there are ways to run off-line pilots, parallel systems, and other formats. Again it's understanding how the project can and needs to be run from all interested areas - Business, Technical, and Management!
How does one choose
All projects will have a varying degree of complexity and delivery needs throughout the whole timeframe. This variation, small to very big, will be dependent on the type of change being delivered, from a standard roll-out of a platform upgrade that is fairly typical for that organization, or a “blue-sky” type change where the development of the solution is ground-breaking/unknown. Even then, either could have an element of the other.
In the early 2000s an Australian Bank was looking to change the Retail Banking Teller System from the old “3270 character-based green screens with very slow desk to main frame communications” to Java-based applications running on a Windows Graphic User Interface (GUI) front end with “prioritized” communications, known as QoS (Quality of service). This was new territory for the Retail Banking as a whole!
In the early part of the project’s timeframe, we needed to develop a Proof Of Concept (PoC), and so the approach was very iterative. This is NOT a “Trial and Error” technique, by the way, as the stepped development approach is, (usually), based on a good understanding of what is needed and how to develop, it helps to check that the solution is on the right path from both technical aspects as well as, and more importantly, the business understanding. Once the core development was agreed and working, the approach changed a bit to be less iterative at the very low development level as now we had a base, however, it was more iterative at the macro level of development and even building the roll-out plan.
Alongside this, some pieces of work were “Timeboxed”, in particular the PoC, (we had to have a decision made as to the viability of the technical solution because the whole programme is dependant on the outcome being successful, whereas some other pieces of work had to complete fully and so because time was less critical, it was more about getting it working correctly, “Work Packages” were used. (An article on Plans/Planning explains this more).
Other initiatives, such as Relocations are driven by different needs and so a different combination of approaches and techniques. It is interesting to note here that there are still time constraints as systems need to be ready for relocating groups, especially when this is happening over a period of time. Other deliverables need to be completed and working properly before the relocation can even proceed!
Decision Time – For the moment
The real indicator for which approach(es), (a combination of approaches), to use, and when to use it/them, needs to be defined, discussed and understood very early in the project, usually during the first phase when looking at the high-level details. However, it is very important to point out here that whatever is understood to be employed, and there might be a couple or more options, during this phase, it is will be refined/decided on during the second phase, when more details of the objective(s) have emerged and a better understanding of what the project needs. It is these last FOUR words that are the key: -
“WHAT THE PROJECT NEEDS”
It is about understanding this very point. WHAT the project needs and WHEN it needs it.
So, even though we may choose and decide on the approach, as a whole, (a hybrid if you like), during the second phase, it is still open to review and change as the project progresses. NEVER think that once decided, that is it. ALWAYS be prepared to review and change if relevant/needed.
This last sentence is one of the core aspects of having “Agility.”
Author Bio
Antony della Porta has experience of over 30 years in the project management profession. He is an established professional in the delivery of strategic business change and an advisor for programme and project recovery with critical systems thinking approach. He has been an Executive Advisor and Director at GPM Global and founded “The Sustainable PM” initiative, which is a platform that is set to help PMs become "sustainable”. He is also an accredited instructor and practitioner for a number of courses in the fields of management and project management.