Ikenga, your Project Manager Robot

NAO-Robot

The future ain’t what it used to be – Yogi Berra

Is Ikenga, your Project Manager Robot, going to be your best friend because it completes your project initiatives on time, budget and quality over and over again? Time will tell what ultimately happens, but make up your mind and get ready for the next technology evolution that can significantly change the ground rules of the way we do business today. The application of artificial intelligence and robot technology in day-to-day business operations is rapidly moving ahead and already changing the DNA of certain industries. Don’t let it get ahead of you, but instead understand the possible implications, benefits and opportunities for personal development and growth.

The main reason why artificial intelligence and robot technology are evolving rapidly is because computation power has reached a level where it is cost effective and able to deal near real-time with massive amounts of data. A front-runner in this area is IBM with Watson, a cognitive computing solution that is able to answer questions and therefore assist humans in making informed decisions.

In their book Second Machine Age (2014), Andrew McAfee and Erik Brynjolfsson explain the characteristics of and differences between the First and Second Machine Age. Over 200 years ago in the First Machine Age, muscle power was gradually being replaced by machines, starting with the steam engine, followed by electricity and other inventions. In the Second Machine Age, wherein we live today and are just at the beginning, knowledge power is gradually being replaced by machines.

There are three forces behind the Second Machine Age: exponential, digital, and combinatorial. Moore’s law enabled the exponential growth, meaning the doubling of computing power every 18 months. This constant doubling has delivered the advances we see today of which many appeared after 2006. The digital force brought us to the big data model that allows us to collect, process, store and utilize structured and unstructured content in massive volumes. The combinatorial force is the innovative power of humans to combine technologies in a way that was not possible before, because of limitations for example in computation power. The driver-less car, Siri, 3D printing, robots are examples of key technological advances of the recent past that are a result of the combinatorial force.

According to Carl Benedikt Frey and Micheal A. Osborne (Oxford University, 2013), routine intensive occupations could be susceptible to computerization over the next two decades. That in itself is not new, because for example in the automotive industry robots have been used for more than a decade. But what is new is the exposure to the services industry. Routine service tasks that are being done by humans today, may be done by robots or other forms of artificial intelligence tomorrow. The researchers speak about jobs in transportation, logistics, as well as office and administrative support. They estimated that 47% of total US employment is at risk. Occupations that require a high level of creative and social intelligence have relatively low risk of being impacted.

What this means is that artificial intelligence and robotics will also enter the professional service industry. Law Times (2014) wrote about the implications for law firms. They mention that Law firms will see nearly all their routine process work undertaken by artificial intelligence, completely changing the traditional associate leverage model. It is primarily the work being done by paralegals and junior lawyers who perform a lot of work that’s fairly tedious.

Pessimists would likely think that the continued evolution of artificial intelligence could end human life as we know it. Optimists would embrace the evolution as an opportunity and see a shift of focus by humans to the more analytical, conceptual and value add tasks, where a high level of creativity, pattern recognition and collaboration is required.

From an optimistic perspective, what can the evolution mean for the Project Manager? Or in other words, what can be some of the tasks that Ikenga can take on?

As I am trying to answer these questions, I realize that a substantial part of project management is non-routine. In many of the process areas of the PMBOK – Project Management Body of Knowledge (PMI), a high level of creativity, pattern recognition and collaboration is required. Perhaps it is because projects, contrary to business operations, are temporary and unique endeavors focused on accomplishing a singular goal . Having said that, projects do create deliverables, lessons learned and other historical content that can be leveraged in similar projects in the future. So projects are creating an enormous amount of big data that can be utilized by using artificial intelligence and robots. With that notion I think that Ikenga can assist the Project Manager as an Expert with the more routine activities like cost estimation, scheduling, and risk planning, but also once there is an approved, detailed plan and schedule available do the greater part of status reporting. Don’t you see Ikenga walking around the project floor seeking input from team leads on deliverable status?

Bas de Baat

Program Manager Enterprise Applications

 

Share

How would Gordon Ramsay keep a SAP project on time, budget and quality?

1415414215122

 

“The minute you start compromising for the sake of massaging somebody’s ego, that’s it, game over” – Gordon Ramsay

Gordon Ramsay is a Scottish born British chef and restaurateur, and his restaurants have been awarded 15 Michelin stars. He is a world-class performer and knows how to cook an excellent meal with the ingredients and resources that are available to him. Gordon is well known by a broad audience through his TV shows. In his latest TV program he guides a number of top talented chefs through an ‘obstacle cooking race’ and ultimately awards the winner with the title ‘Master Chef’.

When I thought about how you keep a SAP project on time, budget and quality, what came to mind is that doing SAP projects is similar to running an ‘obstacle race’. In order to pass all the obstacles you, like Ramsay, need to be fully aware of the quality of the available ingredients and resources. With ingredients I mean things like: standards, leading practices, software functionality, hardware, infrastructure, processes, data, policies, procedures, regulations, performance indicators, etc, and for resources think about: people, vendors, thought leaders, dollars, facilities, methods, tools, etc.

Once you are aware of your capability to deliver, the next steps are to explore the course of the race and its potential obstacles, and to continuously update your plans. This is an iterative process throughout the project lifecycle. Be mindful of the fact that although an obstacle may look familiar to you, it can behave very different. So what has worked for you in the past, may not work this time. Be creative and fully leverage the insights from your team. Examples of obstacles that you may encounter are: poor requirements definition, misalignment of key stakeholders, silo-ed behavior of teams, unqualified people in key positions, poor data integrity, severe software defects, poor testing, indecisiveness of the key decision makers, weak support organization, inadequate organizational change management, insufficient communications, unplanned work, scope changes, resource conflicts, lower than average vendor performance, etc.

Now let’s go into more detail on some of the obstacles and determine actions that you can take:

  • Requirements: when organizations struggle with defining business and technical requirements, there oftentimes isn’t a coherent vision that is well articulated, communicated and shared. Fragments of the ’to-be state’ are lingering and waiting for qualified individuals to take on to put more detail and definition to it, such that they can ultimately be glued together in a high level solution architecture that can function as a reference model for requirements definition. Organizations who initiate a SAP project, must have qualified resources available that deeply understand SAP, for example solution architects. They are responsible for solution management from start to finish, from requirement to implementation
  • Silo-ed behavior: with the implementation of SAP, due to it is integrative nature; organizations are forced to shift from vertical to horizontal behavior as business processes go straight through many functional disciplines. From an organizational change perspective, this is for many organizations a big hurdle to take, especially when activities and transactions shift from one silo to another, for example from finance closer to end users in supply chain processes. The key action is to create the awareness and understanding at all levels in the organizations, and find common ground between the involved functional business teams to work out an effective, practical model
  • Software defects: although you can trust that SAP is thoroughly testing its software, there will always be software defects that require their assistance. Especially when you are implementing fairly new SAP functionality, make sure that you have the right level of attention and support from SAP itself, as there will be cases where the system integrator cannot help you. Get to know the experts

As you can tell, there are many possible obstacles that can derail your SAP project and the potential impact can be very high because of its broad and deep exposure. SAP solutions permeate through the body of the organization and can cause immediate operational disruptions, and it’s on this particular aspect that SAP projects are quite different then other technology projects. It is very important that senior leadership has this kind of awareness in mind at all the times when they initiate, plan and execute SAP projects. Its imperative to start with the end state in mind with a well-articulated vision and roadmap, work all the way backwards to the start of the project, uncover the needs to be successful and identify the possible obstacles that can throw you off-guard. To make that happen, invest in qualified people who have been in the field and know what needs to be done. Or in Gordon Ramsay’s context, identify the ‘Master Chef’ who has proven his ability to cook and can serve you an excellent meal.

Bas de Baat

SAP Program Manager, PMP©

 

 

Share

The best 21 project management quotes

cropped-JPEG72_small.jpg

The wisdom of our ancestors is in the simile – Charles Dickens

Have you ever wondered why people actually read quotes? According to Professor Ruth Finnegan, who did extensive research and wrote a book about it, quotations are at least as old as written civilization. It seems that quotes are often used to connect us with the supposed wisdom of the ancients, and people tend to leverage their insight to deal with present circumstances.

For me quotes work as an affirmation of a thought or an action that I am about to take. Or they serve as an inspiration to explore certain topics that caught my interest in more detail. Or when needed they can help shift, change or reset my perspective on things. And lastly, they can also work as a method to memorize certain concepts or experiences.

The last couple of years I have captured a number of quotes that are related to project management and business transformation. I have put them in three categories: Think, Change and Achieve to put them in perspective:

Think

  • We cannot solve our problems with the same thinking we used when we created them – Albert Einstein
  • Progress is impossible without change, and those who cannot change their minds cannot change anything – George Bernard Shaw
  • All things are created twice; first mentally; then physically.  The key to creativity is to begin with the end in mind, with a vision and a blue print of the desired result – Stephen Covey
  • Plans are worthless. Planning is essential – Dwight D. Eisenhower
  • First comes thought; then organization of that thought, into ideas and plans; then transformation of those plans into reality. The beginning, as you will observe, is in your imagination – Napoleon Hill
  • Make everything as simple as possible, but not simpler – Albert Einstein
  • There are those who look at things the way they are, and ask why… I dream of things that never were, and ask why not? – Robert Kennedy

Change

  • If people define situations as real, they are real in their consequences – W.I. Thomas and D.S. Thomas
  • When trust goes up, speed will also go up and cost will go down – Stephen M.R Covey
  • To improve is to change; to be perfect is to change often – Winston Churchill
  • All change is hard at first, messy in the middle and so gorgeous at the end – Robin Sharma
  • It is always easier to talk about change than to make it – Alvin Toffler
  • Leadership is the art of getting someone else to do something you want done because he wants to do it – Dwight D. Eisenhower
  • Coming together is a beginning. Keeping together is progress. Working together is success – Henry Ford

Achieve

  • If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it – Steve Jobs
  • The secret of getting ahead is getting started – Mark Twain
  • The single biggest problem in communication is the illusion that it has taken place – George Bernard Shaw
  • A dream doesn’t become reality through magic; it takes sweat, determination and hard work – Colin Powell
  • Patience, persistence and perspiration make an unbeatable combination for success – Napoleon Hill
  • To make a decision, all you need is authority. To make a good decision, you also need knowledge, experience, and insight – Denise Moreland
  • Project Managers are the most creative pros in the world; we have to figure out everything that could go wrong, before it does – Fredrik Haren

Bas de Baat

SAP / ERP Program Manager, PMP© | SAP Solution Architect

Share

Is the Price Right? “No surprise” cost estimates

Estimation

“Well, maybe up-teen zillion was too general a cost estimate” – Chris Wildt

Besides defining the project scope and attracting qualified people, estimating project cost can be quite a complex task. What are some of the measures that you can implement to be more certain about the accuracy of cost estimates such that little to no surprises come on your way?

The first measure is to make sure that there is a well-documented specification of the deliverable, whatever that deliverable maybe. In order to get there you must have a breakdown of the product or service that the project will deliver. And because that breakdown is subjective to change, you have to maintain it. At times that can result in change requests from the vendor. Document and document. Although it may not be an attractive tasks to do, overtime it certainly pays off (think for example of business process management and solution sustainment).

The second measure is about process. You need to define the delivery process as well as the scope, cost estimation and configuration management processes. The delivery process requires involvement from the subject matter experts, as they are the most knowledgeable and experienced of how a deliverable will be created. The project leader acts in this situation as a facilitator and involves all key players, from designers to developers to testers up to staff who sustain the solution. They all must come to a mutually agreed to delivery process, that becomes the standard. Periodically review the delivery process and make improvements. When the input is right (specification) and the delivery process is right, the output will meet your expectations. The scope management process is critical for a number of reasons. It tells the sponsor and other business stakeholders what the planned project outcome is in a ‘tangible manner’. Furthermore it forms the baseline of project plan, budget, and the contractual agreement with the vendor. The cost estimation process must be standardized such that all parties understand their roles and responsibilities, and what is required to come to an agreeable price. Full transparency of how the team calculated the estimate is crucial (for simplicity, I am making the assumption that cost and price of a deliverable are the same). And lastly, the configuration management process is important as it sets you up for long term success. If you keep track of the cost associated with the build up or configuration of the product or service, it becomes a reliable benchmark for future requirements. Let’s say for example that a dashboard with operational key performance indictors is a deliverable. Keeping track of the estimated and actual cost, helps you in the future when there is a similar business need. It all sounds very straightforward, but there aren’t many organizations who do it.

The third measure is to include calculation models for cost estimates of deliverables in the contract with the vendor or in an agreed to project standard. Here is a good example: vendors (system integrators) who design, build, test and implement ERP solutions, use standardized models that calculate the level of effort for certain development objects like workflow, reports, interfaces, conversion programs, enhancement programs and forms. Depending on the level of complexity the estimator says that for a medium complex report, it takes 3 days to specify, 5 days to develop, and 2 days to test, so 10 days of effort in total. It is quite common that the client only hears 10 days of effort and a certain price from the vendor, instead of the full breakdown. Depending on the negotiated, overall price of the project, change requests can become the ‘bread and butter’ for the vendor. Especially in saturated, highly competitive markets, where vendors may come in with a relatively low price and try to ‘recover’ along the way. Depending on the type of contract (see a previous post about fixed price), the status of the project and other factors, vendors respond differently to change request, effort estimation and pricing and at times present an unreasonable cost estimate in the eyes of the client. If it is not managed well, it can lead to major conflicts. Why would we let that happen? Why would we not be fully transparent about calculation models instead? When two parties embark on a journey to implement a technology that in many cases is the enabler to transform the business, it is wise to spend energy on those value driven activities instead of debates, conflicts or disputes about project cost. At the start of the project, get concurrence upon a standard that works for both and that, together with the other measures discussed above, will set the project up for success. Consider using industry benchmarks to validate the accuracy of the calculation model.

The fourth measure is about effort contingency. Oftentimes, the initial cost estimate of a new or changed deliverable is nothing more than an order of magnitude, SWAG or guesstimate. The vendor has to go with the client through the specification process first to understand the detailed requirements, before the estimate can be firmed up. Make sure that you incorporate a mark up for effort contingency in the cost estimate (some extra days). This kind of contingency differs from cost contingency. That’s more of a percentage based on a number of conditions and added as mark up on the total project cost. It’s more a safety net for unforeseen and in principle be ‘untouched’.

So in closing, to better manage surprises on the project cost side, strive for full transparency. Meaning: clarity in defining the business requirements, standardization of the delivery process, scope management process, cost estimation processes and calculation models, and finally using an adequate mark-up for effort contingency in the cost estimate.

Bas de Baat

Program Manager Enterprise Applications, PMP© | Solution Architect

Share

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

Share

“Quality is about ruling out coincidences…”

051214-600-mls-balls-major-league-soccer-soccerball

 

Eliminate all other factors, and the one which remains must be the truth – Sherlock Holmes

Being from dutch descent, I obviously have a passion for soccer. Years ago, Louis van Gaal, a well-known and very successful dutch soccer coach gave his point of view of world-class performance, by saying: “quality is about ruling out coincidences.” Years later he completely re-build the footings of soccer club Bayern Munchen, and ever since that transformation, they have dominated the European soccer leagues. And now he is replicating the same principles at Manchester United.

What would Louis van Gaal do if he was a project leader? I think if you translate his principles to project management, many troubled IT business transformation projects most likely wouldn’t have ended up in that state. What would some of his principles look like?

A key principle is to have a plan and alternatives, call it a plan B, that are well-communicated and shared at all levels in the project and relevant business areas. The plan provides a clear sight of the future end-state and the path to get there, in terms of deliverables, approach and time line. There is a common belief that the planning process is more important than the plan itself. The process is a recurring, consistent, collaborative and inclusive activity supported by all key stakeholders and has plan versions at different abstract levels. There are many walk-throughs of the plan with the all the players, and together with the leaders they discuss major risk and mitigation strategies so everybody is well prepared. The core team is far-sighted, able to connect the dots and keen on translating requirements into work products, making estimates and crafting smart delivery strategies and tactics.

The project leader is audacious and creative in finding the most attractive path from A to B given the quality of the players, the business context and other conditions. When Louis van Gaal was the head coach of the dutch soccer team during the last world championships in 2014, he realized after thorough analysis, that he needed to change the tactics from an offensive to a more defensive style. The average age of the team was relatively low and therefore the experience level. He changed the formation from a 4-3-3 system to a 5-3-2 system. That change caused a huge turmoil across the country, because the default formation that dominated the ‘dutch school of thought’ was 4-3-3. Louis van Gaal was convinced of his bold change and trained the team on the new approach in a very short timeframe. They pulled it off by ending in 3rd place by beating Brazil and exceeded the expectation of the Royal Dutch Football Association. Germany won the tournament, and many of their players came from Bayern Munchen. Louis van Gaal was successful because he had an alternative plan and the courage to execute it. He got the buy in from the team players, and subsequently prepared, coached and motivated them to win. He changed before he had to, and knew what it looked like

Another principle is to implement industry best practice project management and delivery processes in the initiation phase including effective methods, tools and reporting. All project staff must be trained in the functional use of this model before the actual work starts. Ideally, the training is repetitive and addresses case material where performance did not hit the quality mark. That’s an effective way to build consistency. Major motivators for talented project staff is to learn new skills and gain experience throughout the project lifecycle. Seasoned project leaders find ways to combine that progressive learning ambition with continuous improvement of team performance and team bonding. An example of that would be recurring ‘lunch and learn’ sessions, where people come together and discuss a very relevant topic, or at times an odd, fun topic to trigger the creative minds.

Knowing what’s important and what’s not and being able to set the right priorities for the team is another principle. The project leader needs to be observant and have an eye for details without loosing side of the big picture. He has a transparent work style, open-door policy and is an effective communicator. Google Executive Chairman and ex-CEO Eric Schmidt and former SVP of Products Jonathan Rosenberg wrote a book about ‘How Google Works’ [2014] and said that one of their key responsibilities was to be a ‘router of information’. They said: “Most of the best—and busiest—people we know act quickly on their emails, not just to us or to a select few senders, but to everyone. Being responsive sets up a positive communications feedback loop whereby your team and colleagues will be more likely to include you in important discussions and decisions, and being responsive to everyone reinforces the flat, meritocratic culture you are trying to establish.”

If Louis van Gaal would be a project leader, he would make a lot of notes, gather a lot of data, conduct detailed analysis and with all of that provide constructive feedback and coaching to the team players. He would share his opinion based on facts, and point the team into specific directions. He may consider doing project analysis, based on video recordings of the team performance and all kind of statistics. This approach is becoming more and more a differentiator in soccer and other sports. Big data and analytics has entered that industry the last couple of years as well.

The use of fact-based data in the decision making process is another principal. The project leader would use it for example to assess where the project is vulnerable and define corrective measures  to be ready in case identified risks materialize into real problems. Together with the core team, the project leader would think through scenarios for areas where any surprise can catch the team off-guard.

There are many more principles from Louis van Gaal that we can apply to project management. They have one things in common and that is their focus on quality. Every aspect of soccer, on or outside the field, must be well thought through and meet high quality standards. That in combination with real-time fact based reasoning and decision making must put the team on the right track for high performance.

Bas de Baat

Program Manager Enterprise Applications, PMP©

Share

How to project-manage the Executive

BusyExecutive

Face reality as it is, not as it was or as you wish it to be – Jack Welch

“All change is hard at first, messy in the middle and gorgeous at the end” is a well-known saying from Robin Sharma, a motivational writer, speaker and leadership expert. The existence of projects is to drive the change that the Executive has in mind. Imagine that you are the leader of an enterprise-wide IT business transformation project that is the centrepiece for manifesting the next growth spurt of the organization. Your work relationship with the Executive is critical to make this initiative a success. How do you manage the Executive such that both of you are effective? Here are 5 management rules you should be aware off and practice.

Understand and challenge the vision: the single most important success factor of any project is a clear understanding of the vision, purpose, impact, and benefits of the project. It is all about a broad and deep understanding by all stakeholders of the WHAT. It takes awhile for the organization to absorb a vision statement. It’s the responsibility of the project leader to facilitate that process by working closely with communication experts and the Executive on crafting messages and broadcasting them to the right audience at the right time and place. The project leader should challenge the Executive on the vision with the objective to sharpen it. It is in the best interest of the organization that the vision is unambiguous and rock solid before you move forward with the planning and execution phase. If internal and/or external subject matter experts are needed in the ‘vision refinement’ process, the project leader takes care of that. Throughout the project lifecycle, the project leader is accountable for a ‘continuity of vision’ process, which means that the future state gets more and more defined in detail from vision statements to blueprints to specifications. The project leader is the linking pin between the Executive and the project and orchestrates a bi-directional communication and collaboration

Have a mutually agreed to plan: Once the vision has sunk in and all internal and external stakeholders sing from the same song-sheet, it is time to get to a mutual agreement of the project plan between Executive and the project leader. In parallel to the envisioning phase (see above), the project leader is working on a draft plan based on strategies and principles that have been discussed with the Executive. The plan has 3 levels, a GANTT for planning at the Executive level, an integrated project plan at the project level, and work plans at the team level. Throughout the project lifecycle, plans get further refined. The project leader is responsible to involve the Executive in this progressive elaboration planning process as required, not only when plans need to be adjusted and re base lined for unforeseen events. Progress and status will be reported at the GANTT level, such that the realization of the vision is transparent to the Executive at all times. Last but not least: always have a plan B…, just in case

Share the real status with facts: The Executive likes to see a coherent, crisp and concise story of where the project stands on a single page every week, and at peak times  more frequently. Use a dashboard displaying the GANTT and status indicators for the key dimensions: scope, schedule, cost, people, quality, issues, risks and vendor performance. Provide factual information for each dimension that is valuable to the Executive and the project. Include a section where you keep track of key decisions that need to be made. Make sure that the overall story has a rolling forward approach, where the indicators speak to the current and previous period status. Refer to other documents where you keep track of detailed project status, for example issues and risk logs. Have them up-to-date and available upon request. Most of the Executives that are accountable for enterprise-wide IT business transformation projects have a hectic work life. In case the project leader does not get the attention that is needed, think about sharing status information in a creative but still effective manner. An example that works well is to distribute the status report as an attachment to an email. The email itself only carries 3 to 5 key messages. Point in the email to action items or key decisions that need to be made. Follow up with the Executive verbally in a subsequent step that can go quickly, because the project leader already gave a heads up by email, and can focus in the discussion on what’s important

Come with options: One of the ground rules the project leader wants to set at the start of the initiative is that options are being presented at the same time as the problem. Options should be realistic and when possible supported by qualitative and quantitative statements. There is a golden rule that the decision maker can select from a list of 3 to 5 options. The project leader is responsible for making a recommendation to the Executive with input from the team. Make sure that the recommendation is the result of an impact analysis and rational trade-off process between the pros and cons

Get the Executive on the floor: Key ingredients to a successful project is the demonstration of Executive commitment and alignment, as well as acknowledgement of the contribution of the organization, team and people. The project leadership team is responsible on a daily basis for people management. Coaching top talent is one of the premier activities in that area. The project leader must establish a recurring platform where the Executive ‘connects with the floor’. Projects that realize the most benefits have the Executive at arms length. They have the Executive participating in key meetings, or conduct town halls on a recurring basis, do walk arounds to meet with project staff, or have social events once in a while. As I wrote in my post ‘Want a World-Class Project Team?’, the people factor is very important, at least equally so not more than process and technology. The Executive as the visionary leader plays a crucial role

With the projects that I am talking about, ’The Executive’ is oftentimes more than one person. A major responsibility of the project leader is to ensure that along the way, the Executives stay committed and aligned. There are 2 key measures to make that happen. In the first place, work with the Executive in charge to get buy in and to build a forceful coalition of Executives. In the second place, make sure that all the Executives receive the same project status information, such that the context of the project is transparent. When everything is unfolding as envisioned and planned, you are good to go as project leader and be successful with your team.

Bas de Baat

Program Manager Enterprise Applications, PMP©

Share

Be on top of your issues and risks..!

warning symbol

If people define situations as real, they are real in their consequences” – William Isaac Thomas

Besides scope, schedule, cost and people, there are two things that you must be on top of every day as project leader: issues and risks. Be grateful to have them, because it is a good indication that you are making progress.

There are a number of steps to take before you actually want to start responding to issues and risks: define what they are, define the attributes and how to document and manage them.

Definition

When you kick off a new project, you want to sit down with the team and discuss what issues and risks are and how you want to manage them together as a group. A simple definition that works well is the following: “An issue is a problem that has manifested and is right there in the present moment, whereas a risk may turn into a problem in the future when certain conditions become real. Both may need immediate action depending on the assigned severity level”.

There is value in revisiting the definition of issues and risks, as well as the importance of managing them adequately, throughout the project lifecycle. For example, at peak times people tend to forget the need to manage issues and risks, because they want to finish more important work. It is the responsibility of the project leader to observe the adherence and compliance to the process, and intervene when required. A coaching leadership style oftentimes works very well at that point. Take a real problem as a learning opportunity and respond to it as a team.

Attributes and Documentation

Make sure that you document the issue or risk properly by using a simple set of attributes. Because they both describe a problem, the attributes are fairly similar. A major difference is that for risks you want to add a time and probability factor to the calculation of the risk rating, which is equal to the product of probability x impact x time, whereas for issue you define the severity level based on impact. For risks, you want to know when it may turn into an issue, and what the likelyhood is of that. If that’s almost certain to happen next week, the overall risk rating is higher than if it’s a month away from now.

The description of an issue or risk follows a particualr wording structure. For a risk it starts with: “There is a risk that “A”, because of “B”, resulting in “C”, where A = risk, B = root cause or risk trigger, and C = impact or consequence

Example: There is a risk that flights get severely delayed, because of extreme weather, resulting in people not able to get to their destinations on-time

If this risk materializes into an issue, the description changes to: “Flights have been severely delayed, because of extreme weather, resulting in people not able to get to their destinations on-time.

The benefit of using a standard wording structure is that people who are responsible to action them, can quickly understand the issue or risk, and therefore quickly address them. The root cause and impact analysis are very important, because you want to give people who are responsible to action the issue or risk, an accurate reflection of the problem, otherwise they may not react effectively.

There are a few attributes that are very important for managing issues and risks effectively:

  1. Short description: Describe the issue or risk and follow the standard wording structure
  2. Root cause analysis: Describe clearly and concisely the determining, causal factors of the issue or risk
  3. Impact analysis: Describe the impact to the business and project in qualitative and quantitative statements
  4. Severity: Its common to use 4 severity levels, for example: 1-critical, 2-high, 3-medium, 4-low. Each level gives an indication of the impact, exposure, and response time.
  5. Priority: Its commong to use also 4 levels for priority setting, for example: 1-urgent, 2-high, 3-medium, 4-low
  6. Ownership: Assign an owner from the project and from the business who have responsibilities for the funtional or technical area that is impacted. The project and business leader are accountable
  7. Status: Follow a simple standard, for example: 1-new, 2-assigned, 3-analysis completed, 4-in progress, 5-completed, 6-closed

The severity level is set by the project team and is an indication of how critical or undesirable the issue or risk is from a solution perspective. The priority level is set by the business and is an indication of how urgent or fast the issue or risk needs to be actioned. At the start of the project these attributes need to be well defined and tailored to the specific needs of the initiative.

Issue – and risk management process

Once you have documented the issue or risk, the real work begins. You want to implement and consistently follow a simple 3-step issue – and risk management process:

  1. Document: Any project stakeholder should be allowed to identify an issue or risk, but not allowed to document it. Keep the number of people who can document them to a minimum. Think about assigning that responsibility to team leaders. The reason behind this is that the people who documents an issue or risk is able to speak about it. Those people are also attending the meetings where the issue or risk is being handled from a project management perspective
  2. Manage: The project leader is responsible to conduct a recurring meeting with project and business stakeholders where issues and risks are being managed. In such a meeting, each issue and risk is being reviewed, and the severity, priority, ownership and status is being set
  3. Escalate: The higher the severity and priority levels, the higher the chance that issues or risks needs to be escalated to limit impact. Make sure that escalation paths have been defined and agreed to by all stakeholders prior to the project kick-off. Agree to response times from decision makers. Think about how you want to involve external parties in the escalation process, for example subject matter experts, mediators or lawyers. Its best to have that all straightened out and agreed to at the front door, before you begin and not when you are right in the middle of it. At that point it is often too late

The day-to-day responsibility of the project leader is to keep the resolution of issues and risks moving forward. A key part of that is to continuously make stakeholders aware of the status and impact. The project leader needs to use his instincts to trigger the escalation process for issues or risks that are stalling. Be on top of them. Without issues and risks there is no change, and without change no achievement and success.

Bas de Baat

Program Manager Enterprise Applications, PMP©

Share

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©

Share

A Fixed Price contract, are you sure?

Fixed-price “If you think that a fixed price contract is going to solve all your previously experienced project issues, think twice”

A fixed price contract appears to be the magic bullet to a number of project management issues, but that may only be superficial. At the end of the day, all of the project management routines still need to be flawlessly executed including the financial aspects, regardless what contract vehicle has been selected.

With a fixed priced contract the customer is making an attempt to transfer the financial risk to the vendor. The transfer is at a cost to the customer and wouldn’t exist, if the parties decided to sign a time and materials contract. The additional cost is a risk premium (cost contingency) that the vendor is adding to the base estimate that if done properly already has an effort contingency. It is quite common to see a risk premium in the 10 – 30% range on top of the base estimate and effort contingency together. So long story short, customers are paying a lot extra when they sign a fixed price contract. Is that worth the money; is that worth the delivery risk? Now, there are customers that want to know what the actual project cost to the vendor is and based on the outcome recoup part of that risk premium. Unfortunately that’s not how it woks, because the customer did not bear the delivery risk and also would not chip in extra dollars if the vendor would experience a cost overrun.

Alongside the risk premium (additional cost), the customer bears the risk that the vendor is not delivering the contracted scope with the expected quality (less business benefits). When a vendor is exposed to a fixed price deal, they are managing the project scope very tight. When the project scope is not well defined in the contract and therefore the level of ambiguity (see previous post ‘Ambiguity’) is relatively high, the project is set up for failure. Oftentimes the expectation gap cannot be closed without a project change request, which most customers do not account for in their budget when they have signed a fixed price contract. It is very likely that the gap is significant; therefore the vendor is raising many change requests over time. The relationship stress that manifests between the customer and the vendor, because of the conflict, can be detrimental to the overall trustworthiness of the parties, and when trust goes down, cost goes up, and speed goes down (see Stephen M.R.Covey, “The Speed of Trust”). As a result, the project slides into a downwards spiral triggering all different kind of consequences.

Managing a fixed price contract is asking for a different mindset from the parties than any other contract vehicle. Scope and schedule must be perceived as equally important for both parties. If not, the project is doomed to fail. There are cases where a vendor managed a fixed price contract as it was a time and materials contract. For quite awhile there was an abundance of resources and everything seemed possible (exaggerating here a little bit), but overtime when the project actuals came in and the scope verification check was completed, the vendor realized that the burn rate was way out of line, and that the only way out was raising change requests (extra dollars or scope reduction). At that point, frantic behavior should not be a surprise to anybody. It is possible that the vendor tells the customer that for certain deliverables they have exceeded the number of hours, and the customer has to pay extra. Or that rigorous testing is not required, because best practices and development standards have been followed consistently, and therefore the risk of failure is low. A customer would instinctively think: “But I have a fixed price contract for that deliverable, the requirements are clearly articulated in the contract, blueprint and specifications. We agreed to the delivery approach, what’s the problem?”

These are just a few examples of situations where a customer might end up with, if they make a fixed price deal. They need to be aware of the buyers risk of paying more (risk premium), for potentially less quality (business benefits), and potentially damage to a good relationship with the vendor, whom they may have been successful with before at other projects. What is then the alternative?

There is actually a few. Customers can simply go for a time and materials contract. There is nothing wrong with that if they manage it well. Or customers can decide to go for a hybrid model, where the basis of the contract is time and materials, with fixed price for specific, well-defined scope items. They can also consider performance-based contracts with time and materials as basis. If the intention is to transfer delivery risk to the vendor (which is a great idea and something a customer must consider), embedding performance-based incentives in the contract is a perfect alternative. More and more vendors are willing to demonstrate skin in the game.

The success of any contract vehicle comes down to the accuracy of the scope definition. Customers need to know WHAT they want (see my post ‘Continuity of Vision’) throughout the project lifecycle. They need to clearly articulate it to the vendor, and collaboratively document it meticulously in the contract. When customers are locked into a fixed price contract, discrepancies seem to be much harder to resolve than with any other contract vehicle. Customers must be mindful of the pros and cons of a fixed price contract when they consider it. Customers should not run into it, because they think they have frozen their financial baseline and they therefore only need to focus on scope and schedule. That’s an act of shortsightedness, which at a certain point in time will be proven to be wrong.

Bas de Baat

Program Manager Enterprise Applications, PMP©

Share