Tag Archives: project success

How companies limit project success

Man in office / Project

It always seems impossible until it’s done – Nelson Mandela

Companies can limit project success and may not even know it. If they do, they tend to ignore it at first and move ahead, often up to the point where it really becomes broadly visible and dismaying. By then the damage has already been done and it’s hard to recover, if at all possible.

Technology-driven-change projects have a massive impact on the organization, because they touch people, processes, and technology all at once and deeply. Before you start the project, you need to take care of a number of derailing factors that can be deeply rooted in your companies DNA.

I will list a number of these factors first, select a few and address those in greater detail:

  • Establish leadership alignment and commitment on vision, scope and strategy
  • Remove silo-ed behaviour of departments and groups
  • Assign full-time, qualified people on the key positions
  • Implement governance structures within the project and outside with external stakeholders
  • Focus the team on the key tasks by minimizing distractions and prioritizing the work
  • Educate project staff on how to execute key tasks and what the new technologies are about
  • Select qualified business partners to help you deliver and act upon their recommendations
  • Adequately resource the organizational change management team
  • Communicate the project scope, timeline and strategies over and over again

The factors that I have picked to explain in more detail below are not necessarily the obvious ones, but they can be very detrimental to the project outcome.

The first factor is about silo-ed behaviour of departments and large groups. Traditional, function oriented companies struggle in today’s fast pace world with cross-functional collaboration. The majority of the leaders of these organizations are still very comfortable in their verticals and do whatever it takes to optimize the fragmented reality of the day for themselves first, and others second. When they engage in cross-functional activities and communications, they appear to work well together, but in reality they hardly do. This is a severe challenge for projects who are implementing enterprise business solutions.

It is very hard to course correct this behaviour and oftentimes requires people changes to remedy. A short term effective measure is to work with performance metrics that stimulate cross-functional collaboration at the executive and mid-level of the organization. Another short term measure is more frequent involvement of the CEO or GM who can bond the team of senior leaders, foster the right behaviour and make key decisions in adversarial situations.

My point of view is that traditional, function oriented business models don’t work effectively in today’s world. Instead, organizations should strive for a horizontal design of their business operations. They should orient their structure by end-to-end business processes and lines of business. It is business process first and then function, instead of the other way around.

The second factor is about distraction and competing priorities. Most people and project teams struggle with getting things done when there are too many tasks at hand at once with similar deadlines. They have a hard time dealing with planned work that happens concurrently. At the same time, they are getting distracted by unplanned work that grows in volume towards the end of a project phase. When the pressure goes up, the team’s progress slowly comes to a grinding halt. People start to point to the timeline being to aggressive. But is it really? What do you need to do on this front before you start the project, and as you move forward?

The biggest step to make or take is to educate the team on how to organize and schedule the work. Make sure that every project and sub-team has work planners and schedulers. Make sure that highly effective communication structures are set up. Make sure that internal and external dependencies are identified and managed. Use a hierarch of work plans and schedules, with a MPS – master project schedule, and TWS – team work schedules that are aligned all the time.

There has been a lot of discussion the last years of waterfall versus agile project management methodologies. Without going into detail in this post, my point of view is that for technology-driven-change projects a combination of both is most effective. As example, the baseline of the project can be waterfall oriented, but when the planned work volume peaks you use SCRUM techniques to get through that particular moment. You can also decide to use agile for certain parts of the project scope, where waterfall is more effective for others.

There is one behavioral element that is hard to deal with when you are in-flight and can be addressed at best before the start of the project. It is called procrastination. Many people have a habit of leaving the work up to the last minute. This can be devastating if they don’t understand what the work is in detail, and when at the same time unplanned work comes up.

When you staff the project team with internal and external resources, be aware of the core personality traits of the key resources on the project. Do not only focus on the expertise that the person can bring to the project, also focus on ability to deliver under pressure and tight timelines, collaboration with other individuals and teams, and verbal and non-verbal communication skills. Get the right team on the ground. From your own internal organization, and from the business partners.

The third factor is about project management capability. Companies limit project success, because the majority of the resources they assign to the project don’t have  the right level of knowledge and experience to manage a project. Let me be more clear on this. Every resource in the project has a responsibility to manage the project to some degree. For the program and project managers it obviously is a full-time responsibility, for team leads and team members it is a partial responsibility.

An example of what happens quite often is an issue that should be reported upwards to the project level, stays far too long at the team level without a decent chance of getting an effective response. When it does finally boil up, the severity and impact has gone up dramatically with less time for resolution. Another example is work planning and execution. It happens regularly that project resources get stuck with their project work, because their functional leader has other non-project work assigned to them that the project leadership is not aware of.

What you also see is that the initiative is not managed as a true project, but more as an initiative that functions as an extension of the departments involved. Let’s say there are two departments leading the initiative. That means there are two circles of influence that overlap. Ideally the overlap would be significant. Project resources operate where the circles overlap. You may call that area the project. In such a situation, project resources tend to go to the home base first to discuss anything that is related to the project. Once that happened, they may or may not discuss it within the project. This occurs because the traditional function or department is stronger than the project. What should it actually be?

There should be three circles of influence. The two circles of the departments and a third circle, being the project. The project needs its own identity with its own leadership, governance and resource structure. With the project assignment, resources move over completely to the project and only report to the project and not to the home base they originate from. At the same time, the company must have a clear strategy of how project resources at the conclusion of the project flow back to the organization. Such a strategy builds trust and gives comfort to the project resources, because they know what will happen in the long run.

An example of a behavioral issue that happens all the time with two circles and not with three, is accountability. When there is no true project (two circles that overlap), the needs of the home base can take precedence over the needs of the project. Resources tend to ignore project leadership in favor of their functional leadership, because they know that in the long run the functional leader has more impact on their future at the company. This is a situation that is not beneficial for anybody: company, department, project and resource, yet we still allow it to happen.

Before companies embark on technology-driven-change projects , they must take care of a number of factors to maximize the potential for success. I am a firm believer that projects do not fail of the technology itself. If they fail or realize less benefits than planned, it is about key decisions the senior leadership team did not make properly before the start, or not adequately executed them while in-flight.

If companies want to deliver projects and achieve the planned benefits, they must set people up for success. If they do that for each individual, they will build high-performing teams and get the anticipated results. Make sure you have got all of the factors addressed before you go.  Investigate what leading practices or world-class standards are and implement them. Use the expertise from professionals in the marketplace to get you off to a right start. Build the right project platform to operate from.

Bas de Baat

Under pressure everything becomes fluid

clock-439147_1920
Nobody works better under pressure. They just work faster – Brian Tracy

There is a misunderstanding that under pressure people perform better. Pressure to a certain degree is fine and can have a positive impact on performance, because people become aware of the fact that things have to get done. But too much pressure will have a negative effect on the quality of output. And if that happens the probability of rework at later stages in the project goes up significantly.

Under pressure everything becomes fluid. In other words, when hitting deadlines becomes the primary driver and focus, deliverables will eventually get done, but oftentimes with lack of quality. People start to demonstrate irrational behaviour, remove standards and constraints, and go the extra mile to get the job done with making sacrifices. This makes sense, because in the devils triangle of project scope (quality), schedule and cost, the latter two are fixed, and the only variable that can move is scope.

When the project schedule is aggressive and tight, the risk of a balloon effect is high. At the start of the project, people believe they have tons of time to complete the work. You actually see the opposite happening. People are focused on scope and quality of output, instead of schedule. But as we go, those two variables start to shift.

What can you do as project manager to mitigate the ‘risk of pressure’?

  • Build a hierarchy of schedules that reflect the milestones, dependencies, tasks and deliverables. That sounds simple, but in reality people struggle to build meaningful schedules. They need to be granular enough for the level you report status. You need to be able to communicate the schedule. Many project managers are challenged to find the right level of detail. If there is too much or too little, nobody else than the project manager looks at the schedule. I would recommend to use 3 schedules. One for the executive level that you use for steering committees and CXO. One for the program or project level. And one at the team level. You build them top down, and validate them bottom up by assessing the work and estimates against the time line
  • Communicate the schedule and report accurate status. How many times have you been in projects, where you knew there was some sort of schedule, but you did not know the details, nor did you have access to it? It happens more than you think and if it does, you can rightfully wonder if there is one. Project managers must communicate the schedule and status at a minimum on a weekly basis at the project and team level. For the executive level and CXO it can be bi-weekly to monthly. Status reports have to be accurate and complete. But how do you know that you something is accurate? For deliverables and tasks that are on the critical path you want to do cross-checks to mitigate the accuracy risk
  • Paint the bigger picture. When people perform under pressure, they tend to loose the big picture. Although you want them to be in the zone for optimal performance, they need to be made aware of what is happening around them. They need to know what is coming up next, and how they impact that with their current output or lack of output
  • Facilitate daily scrum meetings to set focus, priority and urgency. When the going gets tough, the though gets going. You cannot be early enough to start with daily scrum meetings. I am using the word ‘scrum’ to refer to a daily stand-up meeting at the team level, where each and everyone is present and provides input on the schedule and status. The project manager and solution architects are on point to resolve issues on the spot and to keep the work flowing.
  • Open up your toolkit and be creative. When that deadline is looming and smiling in your face, you want to do a step back as project manager and assess, reflect and adjust. It is the only way, to let your creative mind go and provide new and better mechanisms to get the finish line with the best output possible. The worse thing you can do is to get hooked into the pressurized momentum as well. If that happens, it could be game over

Every project gets under pressure. If it hasn’t, it probably wasn’t a real project, meaning there was tons of time to deliver. Project managers need to be aware of this and understand that under pressure everything becomes fluid. When that happens it is time to roll up the sleeves and apply specific techniques to bring the game home with the right level of quality. Most of these techniques centre around better and more timely communication, detailed work schedules, ad-hoc actions to keep things moving forward, and creativity.

Bas de Baat

The Wheel of Fortune

Wheel-Of-Fortune

“Clarity breeds mastery” – Robin Sharma

When we initiate a technology-driven-change project, we all want to start off right. We all want to be successful in the end. Now, let’s put the odd exceptions aside for a second and make the assumption that when you turn the ‘Wheel of Fortune’, it does actually spin to the point where you make a jump for joy, because you have achieved all your goals: 100% project success on all counts.

In reality, the likelihood that you reach that ultimate, optimum state is not that high. If you read the number of articles about why project fail or not deliver what was originally intended, we still have ways to go. The wheel of fortune is highly symbolic and refers to the fact that things go in cycles. There are good times and there are bad times. The main idea behind this mysterious wheel is that you are fully aware of what’s happening inside and outside of you, and that you are taking actions to influence the outcome when required.

So, what can you do to make sure that when you do spin the wheel, you land on an acceptable spot or at least make a significant step forward from where you are today? Here are 3 behaviours that you want to embed in your project organization:

  1. Clarity: Be transparent in your goals, actions and communications; remove ambiguity all the time

My experience is that organizations that were able to achieve their goals through people, process and technology change, provided full clarity of WHAT they wanted to achieve and communicated that to all project stakeholders at the right time at the right place with the right level of detail. They realized that clarity is progressive and subject to change. Therefore they assigned highly skilled leaders to key roles in the project organization, who are mindful of the fact that ambiguity is a ’silent killer’. Think about roles like the project sponsor, project leader, solution architect, functional and technical team leads and the organizational change management lead. They were all aligned, committed and capable of adequately communicating the project goals, solution direction, business impact, project strategies and major risks.

  1. Far-sightedness: Always be prepared and have alternative plans to make things happen

The same organizations had a well-defined, structured and communicated project plan. They consistently went through a recurring planning process, such that the project team and business stakeholders knew what was coming when, why and from whom. At the project level there were alternative strategies and plans readily available in case circumstances required the team to adjust the course. Where possible alternative delivery strategies where followed to expedite or to be responsive in case business requirements were for valid reasons in a state of flux.

  1. Stamina: Never stop, but keep moving forward, also when you feel you are making a step backwards

Perseverance is crucial for all business transformation projects to succeed. “All change is hard at first, messy in the middle and gorgeous at the end” [Rob Sharma]. It’s oftentimes said that technology-driven-change is like a ride on a roller coaster or a bad day on the stock market. A caveat to that statement is that nobody knows when you are about to make a turn or enter a circular loop. Like nobody can accurately forecast the price of oil, it’s the same for managing change. At best you can make reasonable predications based on past behaviour. Organizations who have been successful in dealing with significant change wisely invested in professionals, who know how to prepare, avoid or respond to different kind of scenario’s and sudden shifts in motion. Companies who ‘go on the cheap’ will in the end be less cost effective. They may have saved on project cost, but likely have not achieved the ‘deep change’ that is needed to achieve the end user adoption and planned business benefits.

When you are about to turn the ‘Wheel of Fortune’ make sure that you are prepared. When you land in a spot where you don’t want to be, ignite your action plans and sit through it. A key element of the preparation is making sure that you have the right team. As I mentioned in previous posts, in the end it is all about having access to talented and intrinsically motivated people. It’s rare that process and technology change put the project in a ’troubled’ state.

Bas de Baat

Program Manager Enterprise Applications, PMP© | Solution Architect

Make or Break your Project?

0927_testimonial-800x480

The bigger the dream, the more important the team – Robin Sharma

If you go through my blog you’ll see posts that speak about critical success factors for IT business transformation projects. I have talked about the importance of trust, the impact of ambiguity, how to pick the right people, but also vendor performance, dealing with competing priorities and SMART project leadership.

It is not so difficult to BREAK your project; you can do that in a heartbeat. It is much more difficult to MAKE your project. It all comes down to leadership potential of all internal and external stakeholders, because project success is something you create and achieve together as a well-integrated team.

There are a few, silent ‘BREAKERS’ of success that can be detrimental, throw you off track and ultimately force you to pull the plug.

Singing from the same song sheet

Many organizations that initiate an IT business transformation project put their faith completely or way too far in the hands of the vendor. They rely too much on the vendor’s expertise to design, build, test and implement the solution. For these organizations it is a given that the vendor provides industry leading practices to the project. “But that’s why we hired them” is a comment you hear when organizations realize that their expectations are not being met.

Is this an issue caused by the vendor only, or by both the vendor and the organization? It can actually be both. Every organization should develop in-house expertise of the future state solution, otherwise you are not able to define WHAT you want in clearly articulated business requirements. With expertise I mean: knowledge and experience of the business processes, technology and data.

Does it need to be at the same level as the vendor? It must be at least at a point where you can truly understand the options that are being presented by the vendor, and you can identify alternatives that for various reasons do not come forward. Organizations should consider assigning a solution architect (contract or permanent employee) to the project who can bring that level of knowledge and experience. The solution architect functions as a catalyst to other project resources and brings continuity, consistency and integrity of the design to the team. All key resources should be trained in the new technology at the start of the project, preferable by the technology vendor.

The money that the organization spends on building this solid project team capability must be perceived as an investment. It is a risk mitigation activity that has both short term (set project up for success) and long term (effective sustainment) value.

Vendors who embark on IT business transformation projects should encourage the organization to build up their capability right at the start of it and not gradually overtime. It is in their best interest to work with a client organization that sings from the same song sheet, speaks the same language and uses the same communication matrix, from the starts of the design phase onwards. The quality of the solution design drives the value and benefits that the organization has in mind and is expecting to realize.

Silo mentality

It is fairly common that organizations with traditional structures have entities (departments, units, teams, etc.) that operate in silos. We also know that nothing great happens in silos. IT business transformation projects thrive on creativity, collaboration, communication and a multi-disciplinary approach. Organizations can only attract and retain top talent if they move away from this one-dimensional paradigm once and for all. Top talent that is needed to staff the project and future sustainment organization will quickly move on to greener pastures if the organizational culture does not change.

A major risk of silo mentality is that the project will struggle with the “pave the cow path and reinvent the legacy” syndrome. The future state will be not be much different. As a result it does not bring what the organization needs to achieve cost savings, better customer service levels, accurate management information or anything of that kind that makes it better (world-class) than the organization’s peer group. It is not an easy task for the leadership team to successfully deliver the IT business transformation project in this context. What needs to happen?

Executive Leadership can:

  1. Set a new tone for the organization by communicating core values that go with the future state. There are organizations that define core values in a collaborative manner with their people
  2. Clearly articulate the vision, the path to get there, and what contribution is expected from each of the entities
  3. Model the behaviour that is expected
  4. Actively participate in the IT business transformation program with the intention to inspire, motivate and coach people
  5. Set the right business priorities and make timely decisions when needed
  6. Clarify in what functional and technical areas change must happen to achieve major business benefits
  7. Monitor progress and take corrective actions as required
  8. Assign ‘business transformation’ specific performance goals to key leaders
  9. Source top talent from outside the organization that resonates well with the future state
  10. Implement a reward program that encourages people to think, act and speak differently

Project leadership can:

  1. Make sure that project and relevant business objectives, strategy and plans are always aligned and well communicated
  2. Increase focus of change management activities on stakeholder alignment and commitment
  3. Define and enforce solution design principles that drive people, process and technology change
  4. Quickly identify and remove roadblocks on the design path to change, and actively manage integration points or dependencies between entities
  5. Simplify design concepts as much as possible
  6. Implement an escalation path up to the Executive Sponsor to get fast decisions on design issues and risks
  7. Foster a working climate of collaboration, creativity, communication and change
  8. Conduct demonstrations of components of the to be solution to key stakeholders
  9. Implement quick wins where possible and meaningful
  10. Seek for industry leading practices and share that with stakeholders that resist to change

There are a lot of ‘make or break’ project success drivers to think about when you initiate, plan, execute and close an IT business transformation project. Key is to identify and respond to them properly and in a timely fashion. Stay in control of your own destiny by investing in core project team capabilities and by taking the right actions at the Executive and Project level.

Bas de Baat

Program Manager Enterprise Applications, PMP©