A dream you dream alone is only a dream. A dream you dream together is reality – Yoko Ono

 

Think

In simple terms, organizations do projects to implement new ideas. Where the business leader is most of the times the originator of the idea, the pragmatic project leader shapes the path to attain it. It is crucial to clearly define WHAT the organization wants to achieve. The generation of the idea is just the first step of many.

One of the next steps is to ask WHY the organization wants to implement the new idea. Organizations go through a thinking process where they quantify and qualify the business benefits and associated cost. They often conduct an impact assessment and determine the change the organization must go through to ultimately manifest the desired end state.

Once the organization has a decent understanding of what it wants and why, the final step is to think about HOW to achieve it. There are many aspects that come into play at that point in time. Implementation strategy, time line, methods and tools, required skill set and business partners are a few to mention.

What do you want?

Organizations must understand that this question needs to be answered many times throughout the project. The level of detail is increasing as you go, because experience and insight in the future end state continues to grow. Clear and transparent documentation and communication of the WHAT is therefore an ongoing and primary project task that is often misunderstood resulting in projects delivering less than expected or potentially to fail. The pragmatic project leader is responsible to organize that in terms of specific types of deliverables at specific times in the life cycle of the project.

When the level of detail of the WHAT is increasing as we move along, the level of ambiguity is decreasing at the same pace. As soon as you approach the build phase there can be no ambiguity left. If there is, you know that specifications are not accurate and must be revisited before you proceed.

The following list are examples of deliverable that define the WHAT. I have put between brackets an indication of the level of ambiguity: H = high, M = medium and L = low.

1. Dream collage (H)
2. Vision board (H)
3. Business requirement (H)
4. Design criteria (H)
5. Solution architecture (H)
6. Demonstration (H)
7. Process design document (M)
8. Business blueprint (M)
9. Integrated solution design (M)
10. Functional specification (L)
11. Technical specification (L)
12. Test script (L)
13. Training material (L)
14. Work instruction (L)
15. Business procedure (L)

Defining WHAT the organization wants in a progressive and consistent manner is one of the biggest challenges in IT business transformation projects. “Continuity of vision” is a critical success factor throughout the project life cycle. Organizations must ensure that in the evolution process from ‘dream collage’ to ‘business procedure’ the vision is carried forward by an individual or team from start to finish. The business leader is accountable to delegate that responsibility to for example a solution architect.

The pragmatic project leader is responsible for implementing a robust framework of processes, methods and tools that support the end-to-end definition process. This framework must also includes quality assurance and control steps, as well as measures that prevent the business leader from making definition changes randomly at any point in time.

It is imperative that stakeholders are made aware of the roles and responsibilities, the framework, as well as the risks associated with non-compliance.

That the definition of WHAT an organization wants is a critical step in the overall THINK.CHANGE.ACHIEVE ^TM process may be obvious and logical, but is often not followed meticulously. Here is why:

1. People assume that others understand WHAT they want
2. Business is requesting changes that are not well understood and/or documented
3. Vendors over promise and under deliver (commercial, capability, or financial reasons)
4. A knowledge and experience gap (technology) between organization and vendor
5. Stakeholders from different disciplines are not aligned (vertical organization | silo-ed behaviour)
6. Stakeholders are not aware of the end-to-end definition process, deliverables, roles, responsibilities and risks
7. Any form of non-compliance that is not being corrected

Shortly after the organization has started to shape and define the WHAT, there is another question that must be answered, and that is WHY you want something.

Why do you want it?

The definition of the WHAT is an ongoing process that never sleeps. For the WHY it is exactly the same. Organizations who are about to embark on a new initiative must always answer the WHY question. Depending on what stage of the initiative you are, the answer is different as well as its impact. For example, a change to a business requirement in the testing phase close to deployment can be fatal, because of its impacts to the core of the solution, whereas rolling out a solution to a country that was not in scope before can be accomplished because resources are available and the timing is right.

Organizations often make the wrong decisions, because of a lack of awareness and/or understanding of the impact. And if the awareness / understanding is there, its often an inadequate ranking and prioritizing of the WHAT that pushes things off track. It is the responsibility of the pragmatic project leader to bring that awareness, insightfulness and reality check to the key stakeholders and decision makers. As long as that reality check is based on factual insights it is meaningful and situations can be corrected and reversed. If the executive stakeholder and/or sponsor needs to be involved to steer the decision making in the right direction, the pragmatic project leader, must do that without hesitation. In order to make that happen, escalation paths need to be pre defined, transparent and respected.

The general rule of thumb for answering the WHY is two fold. You need a business case and an impact assessment. The materiality of the WHAT determines the effort to complete these tasks. Less material requirements can almost have an immediate answer, whereas material business needs require a documented process with formal reviews and approval steps. The pragmatic project leader is responsible to orchestrate that process.

Examples of deliverable types that you can expect are:

1. Cost-benefit analysis
2. Business case
3. Impact assessment 
4. Strategic decision document
5. Key decision document

How do you achieve it?

The last question that is part of the THINK step is about HOW you are going to achieve the WHAT. The result of this step must set the entire project up for success. You cannot proceed to the CHANGE or ACHIEVE steps if you are not a 100% confident on the overall approach. The pragmatic project leader is best positioned to determine whether the project team is ready to move forward or not.

Here are a number of items (there are many!) to be considered while answering the HOW:

Implementation strategy – This item is primarily about how the organization is going to deploy the solution when it is ready for use. The typical options vary from a big bang to an incremental approach by function, organizational entity and/or geography. The key decision driver is the level of risk the organization finds acceptable. Risk averse organizations tend to go for incremental, pilot, staggered and phased deployments, whereas on the opposite side of the risk continuum, risk taking organization tend to go for a big bang go live. The pragmatic project leader must provide detailed insight in the various deployment options, their risk profiles and cost/benefits. This is one of those steps where the organization must do sufficient research and listen to experiences from other organizations, the software vendor, the system integrator and industry experts. Be aware that key stakeholders who have defined the WHAT, oftentimes want to achieve that fast. There is nothing wrong with an expeditious process and aggressive timeline as long as it is realistic, do-able and warranted by build in contingencies. The pragmatic project leader must bring that reality to light.

Required skill set and eduction –  You can only start the initiative, project or program when you have the right team with the right mix of skills. As I wrote in one of my other posts, it is key to select talent based on knowledge, experience and personality. These criteria are equally important. Set the bar high and don’t easily walk away from the requirements if you cannot seem to find the right person. The pragmatic project leader must develop a learning strategy and team leads learning plans for each of their team members. Learning must be a key performance metric in the project performance plan. Education is a critical success factor for the short and long term. For the project (short term), organizations want to make sure that they can deliver quality. Organizations also want to bring their people close to the knowledge and experience level of the external project resources as soon as possible to minimize ambiguity and maximize output. For operations (long term), the organization must be able to develop talent that can sustain the new solution and operating model. To make that happen, education and knowledge transfer must be carefully planned and executed

Methods and tools – This item is oftentimes not well taken care off. Organizations spend a lot of time on defining WHAT they want, WHY they want it, and HOW to get there from a time line, business partner and required skill set perspective, but underestimate that methods and tools ultimately determine the quality of the outcome of the project. You cannot simply assume that the vendor brings that to the table, although some do. The pragmatic project leader must organize ‘method and tools adoption workshops’ where the organization and the vendor assess, review and decide what methods and tools will be used. Part of the selection is also the implementation, education and support requirements. Depending on the size of the project and available budget, organizations can consider to assign a ‘method and tools’ subject matter expert, who is responsible to implementation, support and education. Make that a serious consideration and realize that a robust set of methods and tools are essential for crafting WHAT the organization wants.

The THINK step is one that continuously needs to be revisited throughout the project lifecycle. It interacts with the other steps CHANGE and ACHIEVE all the time. It is important to be mindful about that as pragmatic project leader.

Bas de Baat

Business consulting | Program Management | Coaching