Major Reasons for Projects’ Failure

I have been blessed to work in the IT industry now for over 12 years and have been part of numerous projects. I have worked with both IT and business people and taken part in many projects. Throughout this journey, I have used both the traditional project approach and Agile approach (read Vanilla scrum). One thing that I have learned is that projects can easily be derailed and can easily fail even when the project team believes that they have done their best.

Often, there are early pointers that are not heeded until it is late and that is why projects easily fail. Frankly though, there are times when the project team has done their best, but then other circumstances beyond their control leads to project failure. As a project manager, Product owner or Scrum master, there are certain things which you can spot, that can help you to take action early enough to avoid such failures. In traditional project management, initiation and planning is always done upfront, which helps to reduce uncertainty but then the project becomes rigid to mid-stream changes. This can both be good and bad for the project depending on the project type, stakeholders, organizational strategy and culture, project duration and so on. Agile on the other hand introduces flexibility to accomodate change and reduce uncertainty. It’s inbuilt monitoring and control integrates risk management which reduces failure rate but then this is not feasible in all kinds of projects. From my experience, the following are the common major reasons for project failures regardless of whether the project is plan-driven or value-driven:

Failure to focus on business value and focusing instead on technical detail. This is quite common where the project team is highly involved in the project management and the project manager/product owner cedes some authority or is under involved. In the worst case scenario, the team could be comprised of inexperienced members, unaware of what is expected of them. In a past project, I have experienced project teams working without understanding their contribution to the business value. As a developer, one easily slides into technical field where one is familiar with the working of the project and easily sidelines the business part. The end result is that there is no well-established and clear link between the project and the organizations key strategic practices. The project plan needs to cover the planned delivery, the business change required and the means of benefits realization.

Lack of properly established clear accountability for measured results. The management (PMO) must support project managers by creating a clear view of the interdependencies between the projects, the benefits, and the criteria against which success will be judged. It is necessary to establish a reasonably stable requirement baseline before any other work goes forward. Requirements may still continue to creep. In virtually all projects there will be some degree of “learning what the requirements really are” while building the project product.

Inconsistent processes for managing unambiguous checkpoints. Projects are often marred with unambigous checkpoints , from procurement to complex decision making. Successful large or medium sized projects usually have software measurement programs for capturing productivity and quality historical data that can be sued to compare it against similar projects in order to judge the validity of schedules, costs, quality, and other project related factors. The lack of effective quality centered mechanisms can be a major contributor to both cost and schedule overruns. project managers should learn how to use their lessons learned register or scrum masters should also used retrospectives and daily scrum meetings to gather information and use the PDSA Deming’s cycle throughout the project to ascertain project progress.

Poor and inconsistent methodology for planning and executing projects. There should be a detailed plan developed before any release date of a project is announced. both plan-driven and value driven should incorporate this in their working processes. It is not unusual to hear extremists insist that agile is not about planning. I differ with this and underline that agile actual has more planning than traditional project managerment. The difference is that they don’t do alot of upfront planning, rather it is “just-in-time” planning and with less documentation. But it has numerous integrated planning processes in a project lifetime. Again, inadequate planning is one of the major reasons why projects spin out of control, whether early or in the latter phases of the project.

Include the customer at the beginning of the project and continually involve the customer as things change so that the required adjustments can be made together. It has been observed that successful projects occur when end users (customers) and the project members work as teams in the same cubicle, although this is not always possible. Projects are less likely to fail if there are informed customers giving meaningful input during every phase of requirements elicitation, product description and implementation. The customer needs to be asking, “how are the project result used over time and what do I get out of the results?

Failure by the project manager or Scum master to manage and motivate people so that project efforts will experience a zone of optimal performance throughout its life. This involves managing and retaining the most highly skilled and productive people. Knowledge is money. A project team made up of higher paid people with the right specialized skills is worth more per dollar than a group of lower cost people who need weeks or months of training before they can start to be productive.

Lack of tools and techniques to produce consistently successful projects. The project team must be skilled and experienced with clear defined roles and responsibilities. If not, there must be access to expertise which can benefit those fulfilling the requisite roles. This reinforces the first point above on the damage that incompetent team members have on a business.

There are definitely other reasons that could underline why projects fail, depending on several other parameters. However, this article has focused on the most common ones that override the project type, organizational size and so on. So what made projects fail in your team, in the past? Please share.

Project monitoring in BRM 1/2

Project monitoring in project management is a very important task that helps the project manager to keep track of the progress and remain alert to any changes both internal and external. PMBOK defines it as

“The process of tracking, reviewing, and reporting the overall progress to meet the performance objectives defined in the project management plan “

This is vital for decision-making activities within and outside the project team. As a developer, I have always been fascinated with tracking project development in JIRA and see how the sprints progress as they move from one phase to another and draw closer to the closing date. I have learnt however that in project management, its something different altogether though they have lots of similarities. It is normal to see project managers do it, for the sake of fulfilling the project management plan but without really being keen on it’s effectivness. Some of the areas where project monitoring can be found useful include: Clarification of the project’s objectives, linking of activities to objectives, reporting of project progress to management and helps the management to be aware of the projects status and potential risks.

This is a key motivator to both management and the sponsor to complete the project within the given budget and time. In the development of a software, this will typically start from the time the project manager helps the team why they have to develop the software to the time the software is actually released as a deliverable. That is, from the time the stakeholders understand what the project is about to its development completion. It is normally a continous process addrssing any performance issues that may rise along the way to the future project status.

A project manager needs to master his area of domain and know which data is necessary for making decisions. Decision-making without a proper foundation makes it difficult to convince the stakeholders of its viability and may also be ineffective. Enter project management and it means that decisions are sound and reliable based on the outcome of the monitoring process. Just like at home where you would keep an eye on a toddler, monitoring them closely on their movements, so is project management. It is the toddler, that you would not let go closer to a staircase alone, or to the washing machine. As a project manager, you will certinaly not let the project unnecessarily be exposed to risks that may be costly. To have a better and proper monitoring of the projects, the following input documents are necessary; project management plan, project documents, work performance information (project scope, control resources etc), agreements made (procurements) and any other cordination documents such as risk register and risk reports. With such input, there should be enough information to make well-informed and sound decisions on

1. Whether tasks are being carried out correctly as expected.
2. Are there unforeseen risks such as potential price rise on components or products?
3. How does the team velocity rate against project workload?
4. Are there project components that should be changed or dropped? And what will be the impact of such changes?
5. Does the project still mirror the projected strategic goals?

And nothing good comes easily. Project monitoring is a tedious task, that requires concentration and keenness. Having automated tools and technologies can however simplify the process. Many software platforms today, provide addition add-ons that provide such excellent services. To improve the project managers effeiciency in project monitoring, the project manager should consider using their expertise to make the correct judgement, perform data analysis (cost benefit analysis, trend analysis, alternatives analysis etc.), decision making tools and collaborations in meetings. These are some of the avenues that data from the first step can be used to keep the projects well monitored. Several aspects of project monitoring should be considered, including but not limited to:

1. Parameter of project planning such as effort, costs, schedult, timeframe etc.
2. Stakeholder committments. Could be external or even internal customers.
3. Project risks that arise along the way as well as opportunities that may show up including people, tools, processes etc.
4. Data Management: Monitor all the configuration items, including software, hardware and project documentation.
5. Progress reviews: Conduct and manage the project progress reviews with the help of different techniques which includes the work progress of team members, client meetings, milestones reviews, etc. Based on these activities, various status reports are created, which are shared with the stakeholders as well.

As the project manager keeps track of all these aspects of the project, it also enhances the projects capability of delivering deliverables within the expected time frame and budget. It also increases stakeholder confidence to know that the project is sailing as planned. Tommorrow I will shortly focus on this area and explain how to actually track a project as a project manager. Don’t miss out.

Work Breakdown Structure, fine tuning the workload 2/2

In my post yesterday, I talked of WBS, what it is and when is it created. Today I will continue with the subject, illuminating why this document is critical for a project’s success. I can honestly admit that it never occurred to me how important and useful this document is. I have worked on numerous projects but the planning was not that detailed as this document makes it to be. It not only gives you a better overview of the workload, but also enables you to confidently hand over a deliverable that meets the strategic goals of the organization. The following are some of the benefits of this document in a project framework.

Better organization: With a detailed and well planned WBS document, there is almost no work sippage, which can occur unnoticed. The project manager remains alert to the workload of the team, whilst the team is aware of what is expected of them in terms of deliverables.

The team is therefore able to work in anorganized manner and eliminate any goal unrelated work within the project scope. The scope of the project becomes the center of focus and increases the chances of the work being completed within the defined time frame and budget. As a project manager, it gives you a better edge in communicating also with the other stakeholders. For instance, a sponsor will be convinced why the “new feature” has to wait until the next release cycle or it may cause the delay of the project.

Team communication: The WBS provides a better platform for the team members to understand how their input into the project fits into the overall project management plan. As team members begin to understand this, they also put more effort to make their impact more visible. For instance, an IT department implementing a security plan, with 10 members may not be easy for each member to understand their role. But lets say that the workload is divided into wireless security, servers zoning, DMZ, VPN and so on as work packages, then each member begins to see their input in the assigned area as being important. An audit of the whole process becomes a success, only if the individual members implemented the plan in the WBS. It gives them a better chance to be more detailed in their area of implementation, while providing an easy way for all of them to communicate the progress of the workload. This facilitation of the workload amongst team members and also with stakeholders, also improves cooperation and effeciency.

Improved agility: Changes in a project are inevitable but it is their feasibility and consequences to the project management plan that always causes problems. With a WBS, new changes can be incorporated and the project manager is able to see how this affects the project scope. These changes could be additional work on the existing one or removal of some items. This makes the contribution of each work item as granular as possible, making it possible to see what and how the changes in the WBS affects the project plan. This is very important in preventing project creep.

Better resource optimization: The WBS provides the project manager with a better overview of the need personnel, cost and budget. Going back to the previous example, if the same security exercise was to be conducted for a government ministry rather than a company, then 10 staff will be insufficient. To reflect the same success at company level to the government ministry, then more personnel staff, budget and time planning will be required. These are however unachievable, if the workload iis not there. As the work is broken down into packages and even smaller pieces, it becomes easier for the project team to make finer and accurate estimates for the resources.

Projects center of gravity: The WBS is the center of focus for any project. It is around this document that the other documents will revolve around making management, execution, coordination and monitoring of the projects easier. The documents created after the WBS use it as a bridge to communicate to the other involved persons in the program and portfolio.

So, there we are. I have missed so much in my past projects, often working with sticky notes or scribbled papers. These didn’t have the satisfaction of the above named points. I am surely now wiser than I was last night. 🙂

Guiding small teams through project management

Guiding small teams through project management need not be difficult as we saw yesterday. With proper practice and the right governance and management tools, it can actually turn out to be fun. The cohesiveness in the team though at times can turn out to be destructive, as it may turn out that team members have no clear cut tasks. Most of the times it is expected that the team members are dynamic and have no specific defined roles. In agreement with Amazon CEO, Jeff Bezeos, the size of the team should not be larger that they cannot eat two pizzas to their satisfaction. I agree with this analogy because as soon as the team exceeds this size, decision making may become a nightmare. Not only this, but it also becomes difficult for the team to work within the specified border of governance and project management framework. The nature of it’s size may even at times make the project manager be drawn away from management to performing the actual tasks, leading to vaccum in leadership, which is not the intended purpose. So what do small teams need in order to move forward? 2 things summarize it all as we will see shortly.

Team flexibility: While it is true that having specific roles may not be feasible in such small teams, still the project manager should try as much as possible to have team members assigned specific roles which are they are primarily responsible for. Then within the team, there should be a second team member who is secondarily responsible for the same task. This means that if one person is sick, goes on holiday or quits the company, then the team is still capable pf performing. While staying true to the ideals of BRM, the team lead should aspire to ensure that each member strives to work towards delivering benefit and value for the company. There are two main advantages of this approach, firstly, each team member feels responsible for what they are doing and get a value of appreciation for their work. When members feel valued for what they do, their dedication and focus becomes even great and both the company and the member benefit from get work synergy. Secondly, there is internal growth within the team as members refine their knowledge and expertise in their specific roles and keep the growth tendency on progress. To avoid getting a blurred vision, the project manager while remaining flexible, should still follow the guidelines of project management as defined in PMBOK and ensure that the right processes are followed for initiation, execution and sustainment stages of the project. Flexibility should not be easily mistaken to mean that the project manager should embrace projects with open arms, without any project charter documents that guide the purpose of the project. This in most cases is the number one killer in teams, as team members struggle to understand what they should work on, and what is expected of them in terms of deliver. The PM should ensure that the initial phase of the project follows project management as explained by PMBOK, by receiving the project charter. This should be followed by dissecting the project charter and linking it to what is actually to be done. This step helps to define the scope of the project and gives the project manager to know the capability of the team. For a small team, this means that they don’t have to spend time trying to understand what is expected of them, rather they spend time executing the actual project.

Organization and communication: The team, by nature of its size, should not struggle with communication, or so it would be expected. From my personal experience, I have worked with teams , where communication was dysfunctional to a point of the team almost splitting. This is usually fuelled by poor mindset or incapable leadership to lead the team within the right company governance. Stand-ups, team building and motivating team members should be the mantra of a project management. The the work load of the team becomes easily bearable when team members thrive in a good working environment with good overview of what they are expected to deliver. As we have seen before, with a proper detailed “What to do” document, containing the project components, team members work confidently. There is a sense of security in knowing that there is good organization and guide inexecuting the project to deliver the deliverables within the specified time frame and budget. At times though, the traditional project management requirements may not fit well in mini projects that take roughly a week to complete. In this case, the project manager should devise his own way of managing the project without creating unnecessary overhead, but still ensure that the project does not derail. It may not be realistic for such projects to incoporate all aspects of project management like cost, risk and procurement management as these kind of projects are usually improvement of an existing product.

Since team members will in most cases be contributing to most of the projects, it is importnt that knowledge sharing is encouraged within the team and the manager ensures that the team has a vision which is served. Simple project management tools should at this point be used, to encourage easier, open communication with better transparency. While using project management to deliver the project’s deliverables, the team should regularly undertake sprint planning to ensure that projects are prioritized and executed according to the strategies and goals of the organization.

The bottom line in such small teams is that they should keep things simple but practical without any fear of trying to be innovative. Use the right tools that fit the size of the team and makes the team’s work rate better. The project manager should maintain project ownership and find a good balance between the business requirements of the organization and the available resources at their disposal.

Projects evaluation in portfolios

Before today, it never occurred to me, what makes companies invest in the projects they set to do and how they ensure that they are in the right direction. Well, thanks to project portfolio management, this can be done articulately and strategically, to increase chances of achieving strategic goals and objectives. How are these done within a BRM framework to realize the benefits and values for the business?

If an organization engages in effective project portfolio management then they become better placed to accomplish completion of projects which make significant contribution in achieving strategic goals. Of course there is also need to ensure that good decision making processes are put in place if these are to be achieved. Most organizations use guided factors to achieve their objectives and have also developed their own processes and tools. What is common though amongst these factors are: It should be possible to monitor the projects to ensure that the portfolio remains on track as well as being able to adjust the portfolio when changes in strategy or portfolio dictates so. Continous evaluation of the project portfolio not only ensures that the projects remain on track to achieve the objectives, but also helps subsidiary portfolios, programs and projects to work together towards a common goal to deliver value. It is therefore important to measure the performance of individual projects and consolidate them in a mathematically meaningful way which mirrors the strategic importance of the constituent projects.

Project portfolio management process and its integration within an organization’s strategic planning process should be tailored to the company’s needs and processes. The most common approach to choosing projects within a portfolio always follow this path; identification, evaluation, selection, monitoring and controlling of projects. I have to add that these should not be religiously followed but as PMBOK suggests, they are good to be used as guidelines to increase the chances of realizing the strategic goals. Decision making models are routinely used in this process, with a set of preferred alternatives and defined criteria to choose the right projects. Several executive managers whom I have interacted with, noted that this is usually an intense process and may take several iterativly planned cycles as well as flexibility to adapt to factors affecting organizational objectives. Most important during this phase, is the prioritization of goals in strategic planning which is fundamental for effective portfolio decisions. In some cases, companies hire decision analysts and decision makers who work alongside the company’s business analysts, to help the company refine the project portfolio and help the portfolio manager to have a better overview of the projects. This is necessary when taken into consideration that organizational objectives do not have the same strategic importance and therefore need a different approach in prioritization.

In the next post, I will go deeper into the different selection techniques and see how these are done and what PMI recommends.

Dealing with generational gap in a team as a project manager

Generation gap in a team can be viewed as God-sent or the source of a team’s curse. Last week I discussed about the common pitfalls that are abound to arise within a group especially if there is a wide generation gap between the members. I explored how ambition and experience can turn out to begative rather than a source of strength. Today I will focus from my experience, how these can be dealt with and what PMI knowledge should be appicable. Differences in any team are inevitable and are infact healthy. However, these can be detriemental if the differences threaten the unity of the team or poisons the working environment.

Open communication

A good project manager is able to spot these differences and stem a fallout long before they occur. The PM is able to guide the team so that they discover their differences and use these differences to build on to their relations, resulting in a constructive environment. A workplace that comprises of baby boomers(1946-1964), Generation Xers (1965-1976), Generation Yers(1977-1990) and Millenials (1991 – ), will require a project manager who promotes open communication between them, to bridge these gaps. It helps to build the strengths and skills of the team members at an individual levle but also improves cohesiveness. I have been in terms where each of these generational groups, think that the other generations are loosers or too loud or reserved. There has always been some nasty label attached to some team member who the others perceive to be difficult to work with. With open communication, such barriers can be easily overcome and the whole team can work progressively towards the strategic goals to be met by the project’s deliverables.

Mentorship

Project managers who aspire to have great team members should drive mentorship in their teams. And mentorship does not equate to parenting here. It simply means that the mentor, who is possibly older than the mentee(s), gets a privilege to share their experience whilst the mentee(s) get the privilege of quick learning. There is no one who is piggy-riding or bossing the other one around. The mentee should be encouraged to challenge status quo while the mentor should see an opportunity to learn new ways of doing things. It is here that outdated experience is dropped and new ones crafted.

Organization governance culture.

The project manager should always ensure that the organization’s governance culture is well known to the team. To resolve conflicts easily, the PM can resort to do this in privacy with each party or engage his superiors where there is need to do so. The team members should feel comfortable working in the team, knowing that they have a defined governance system to cater for their interests. In cases where the elderly employee has to report to the younger colleague, it is important to encourage the big icture thinking so that respect is maintained. Failure to do so, may lead to a team member feeling inadequate or unappreciated for their contributions.

Does generational differences threaten benefit realization in an organization?

I was recently confronted by one of my colleagues who got confirmed to his position after the probation period was over, on why things were running in the IT department as though we were still in the 90’s. He went on to rant about using old servers-backup technology to choice of employees computers and keyboards. He even explained that he could not understand why the company was still developing most of its applications in java yet there were newer software programmes which were the “in-thing”. He even went ahead to claim how he could rewrite another application in python in a shorter period and get it to work. As we listened to him, we realized that he had a valid point, though he needed to be in the company for some time to understand why things were the way they were. It is not uncommon to find new and fresh graduates who are itching to put their knowledge into practice and experiment everything they have learnt from university. Indeed it is a good thing, but in most cases they turn a blind eye to all other factors that play a role in realizing the objectives and goals of the company. It is also not unusual that these are relatively young employees with limited experience. Again, I want to be clear, there is nothing wrong in improving processes and injecting new knowledge to current processes. Infact it is most welcome as it helps the organization to stay conscious to current trends.

So what is the problem in letting old practices go, we may ask. At most workplaces, there will always be employees with different generations trying to seek a balance in their work place. It is nonetheless not easy for these different generations to understand their diversities and diversant thought processes and use them for the benefit of the organization. For instance, an IT team that has to collaborate in designing, development and testing of software may have problems with generational gap, so much that it may lead to communication gaps and conflicts. While the young designer may wish to have sleeker features in a software, the middle aged developer may be focusing on the platforms the software will be running on and the elderly scrum owner may be focsuing on the planned benefits for the organization. So what causes this disjunction? We will see shortly.

Communication Style: Generational differences is quite evident in the ways people prefer to communicate and collaborate at work. The middle-aged and older generation prefer emails and phone calls while the millenials may prefer face-to-face talk. Facial talk may be ok where a single person or few people are involved but may not be viable when there are many people to be communicated to. A good case is uring the morning stand-ups in a scrum team, where this is preferable. However it may not be the case when a team need needs to cordinate with an off-shore team/customer. It may also be the case that there is need for decision-making or archiving for relevant information. These may seem like minor differences, but they can be big detriementals to realizing the benefits. There will be no harmony in the team and the output may not meet the desired results.

Cultural Differences: Companies are introducing cultures in their work place to get their employees to bond more as a team. This at times may fly off on their face. A company tour to the city for christmas dinner may be appealing for the millenials especially if they are single, but not for the elderly portfolio manager, due to different generations. The younger employee may come to work motivated and satisfied, ready to work even harder to achieve his targets. The elderly employee may just feel “it is business as usual”. An unmotivated employee does not work at full capacity and may just work to get the job done but not feel the need to go an extra mile in delivering splendid results. They don’t feel accountable to their results. It is not a wonder then that sometimes a product growth takes longer such that it may be driven out of the market by it’s competitors.

Working tradition: Teams with wide generational differences normally experience harmony problems when they are needed to work and collaborate together on a project. The older generation quite often approach different projects with a “template” mindset to get the job done. This is done, not withstanding the disparity of the planned benefits in the two projects. The younger generation on the other hand may quickly wish to implement what they have recently learnt from an online course or just want to please the leadership. This may be done without any consideration on the business needs of the project or how feasible and robust the provided solution will be.

Such factors do not spell success in an organization. They may lead to differences and conflicts within a team causing higher employee turnover in a company. As new team members come in, it will obviously result in delayed project completion, inflated project budgets and unsatisfied stakeholders. The end results are that the planned benefits are not realized and the company does not achieve the values it has in sight. But all hope is not lost, as a project manager, how do you deal with this and ensure that there is good working harmony in this generational gap? Find out more in my blog, next week.

Aligning business processes to achieve strategic goals (Part 1)

This is the first in the 4 part blog about BRM and benefit value in an organization. Benefits management is crucial to any organization if the strategic goals are to be met. Every organization goes in to business with one goal, to gain some benefits from the investments made; in the context of portfolios, programs and projects. There are better chances of achieving this, if there is proper and established approach to Business Realization Management (BRM), a great driver to project success. One of the reasons why most projects fail, is because they fail to consider the benefits that the business inspire to achieve but rather get so much engrossed with the delivery of products and management of deliverables.

Why BRM?

To forge a greater working capacity between IT and the business environment, BRM is needed to be the mediator that harmozies IT operations with the business strategies of the company. IT contributes to a company’s services by demonstrating it’s value and relevance to the business by helping an organization to prioritize projects and ensure that portfolios, programs and projects are well aligned, with the technology that maximizes ROI (Return on investment). Shortly put, it helps to bridge the gap from the actual planning of a deliverable to realization of maximum measurable benefits. Programs and project managers are usually tasked with securing value creation in the organization is achieved, through creation of a dialogure-friendly environment where different departments work towards the right conditions for success. To have realistic chances of aligning business operations with the strategic goals of an organization, the project manager should be responsible for strategic alignment of projects within a program while the portfolio manager is responsible for strategic alignment of programs. In simple sterms, BRM is the chain connecting a business strategic goals and the benefits realized.

How company culture influnces BRM

Company management plays a significant role in building a culture and practice within the company’s structure, that is tailored to meet this approach. When there is a positive company culture which nurtures accountability and collaboration, it quickly becomes possible for the company to move forward and work towards their strategic goals and a guided path in decision-making. The involvement of management and executive leadership in aligning the key three levels of a product development cycle (portfolio, program and project managers), are the steering factors in adapting the best practices of BRM to fit a company’s culture and improve benefit realization and sustainment. The three key steps which are used in implementing BRM are:

1. Identifying benefits – In the initial phase of the project, it is important that the benefits to be attained are well addressed within the business case. It is a key decision-making moment, where management should ensure that the projects’ benefits are aligned with the strategic goals and objectives of the company.
2. Benefits execution – This is guided by a benefits execution plan in which key performance indicators are continously used to monitor progress as well as discovering new benefit opportunities.
3. Sustaining the attained benefits – This occurs post delivery of the deliverables where an evaluation is performed to review the execution phase and the goodies and failures along the way.

To further understand why most businesses struggle with BRM realization in an organizational context, continue to the second series.