It always seems impossible until it's done \u2013 Nelson Mandela\n\nCompanies 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.\nTechnology-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 company's DNA and culture.\nI will list a number of these factors first (not meant to be a comprehensive), select a few and address those in greater detail:\u00a0\n\nEstablish leadership alignment and commitment on vision, scope and strategy\nRemove silo-ed behavior of departments and groups\nAssign full-time, qualified people on the key positions\nImplement governance structures within the project and outside with external stakeholders\nFocus the team on the key tasks by minimizing distractions and prioritizing the work\nEducate project staff on how to execute key tasks and what the new technologies are about\nSelect qualified business partners to help you deliver and act upon their recommendations\nAdequately resource the organizational change management team\nCommunicate the project scope, timeline and strategies over and over again\n\nThe 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.\u00a0\nThe first factor is about silo-ed\u00a0behavior\u00a0of 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.\nIt is very hard to course correct this behavior 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 behavior and make key decisions in adversarial situations.\nMy 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.\nThe 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?\nThe 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 hierarchy of work plans and schedules, with a MPS (master project schedule) and TWS (team work schedules) that are aligned all the time.\nThere 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.\u00a0\nThere 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.\nWhen 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.\nThe 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\u00a0 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.\nAn 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.\nWhat 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?\nThere 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.\nAn 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.\nBefore 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.\nIf 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.