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.

Work Breakdown Structure in Agile Project Management

Last year, I wrote a post about the Work Breakdown Structure (WBS) which opened let to many questions from my readers on how this differs between the traditional project management approach and the agile management approach. One reader in particular asked whether WBS is still valid in today’s project management industry, considering the vertality of the industry. I have summed up the discussions sent by mail, to make an open discussion on this topic in both the traditional and agile approach.

While WBS is importand as part of the scope baseline, it is true that it can be demanding in agile, especially because agile is founded on the tenets of acceptance to change. This is because, it is not necesarily the same activities that have been defined in the WBS that will be the same for deliverables that lie further into the future. The same deliverable may be delivered, but the activities may have changed in the course of the project.

The work breakdown structure (WBS) as used in the traditional planning, is good at identifying the actual tasks to be performed as identified in the project scope statement, easing tasks-assignment to team members, ultimately helping them to identify how their contribution fits into the big picture (PMI, 2006, pp. 5-7). This boosts team-morale and productivity. Additionally, its use to create a detailed action plan also contributes in safeguarding continuous progress towards earning value as each team member works on an assigned task. The structure acts as an assurance that the project scope is decomposed to cover all the necessary activities to be
performed in completing a deliverable (PMI, 2017, p. 158). This is important in the efficient management of resources, since it relies on a realistic project plan constructed from the structure, consequently enhancing accountability and transparency. Moreover, since it provides an overview of the activities required to contribute to the project’s goal, it reduces the burden of tracking how well each task matches the deliverables. Finally, the structural design of WBS in traditional planning makes it easier to identify potential risks, likelihood of occurrence, and how they can be managed.
The structure however, has a high risk of being too detailed at the work package level, due to poor definition of “done”, making it unmanageable. In such cases, it can easily lead to micromanagement by insecure management, causing resentment and distrust, inefficient resources use, and difficulty in data aggregation over the levels (PMI, 2017, p. 150).
Its’ also cumbersome in managing changes that mirror the actual status of the deliverables due to the time and effort associated with the process, which can be a major shortcoming since projects by nature have a high likelihood of encountering changes. This leads to a derailed WBS that doesn’t reflect the actual status of the project plan especially for changes that lie far in the future, creating room for scope creep, missed deadlines, incomplete deliverables or even budget overrun (PMI, 2017, p. 150). Lastly, it can easily be misinterpreted as a project plan.

PMBOK guide edition 6, discusses about creation of WBS in chapter 5.4 and underpins the importance of WBS as providing a framework of what is to be delivered and done once or predefined stages in the lifecycle of a project. It further states that the work packages groups activities where work is scheduled and estimated, monitored and controlled. But it also explicitly states that work in this context is not necessarily the work done but can also refer to the outcome (work products or deliverables) and not the activity itself. Agile introduces Feature Breakdown Structure (FBS) which enhances this difference.

FBS, instead of using activities in the control, planning and work packages, it uses features and stories. This distinction is important for the agile team, because they don’t have to worry about the work series to be performed but rather focus on shipping a functional deliverable, within the defined time and resources to meet the defined deliverable objectives. The structure is used in agile approach of planning projects and is centered on user stories
which belie the strength of agile by delivering values to the user at the high level of the hierarchy. This supports continuous delivery and integration, allowing customers to get quicker value, as the team remains focused on delivering shippable products rather than focusing on the work to be done. Unlike in the WBS, this abstraction of implementation from the deliverables is important even for products that lie further in the future, reducing the risk of being derailed from the project scope (Wettergren, 2020). Second, it supports just-in-time story development, eliminating requirements
specification and allows a team to still focus on deliverables while accommodating changes even later in the project.
This enables the team to have better evaluation of the impact of the decisions made at all levels of product development through accommodating improved and detailed definition of deliverables, hence maintaining the relationship between a product deliverable and its constituents (PMI, 2017).
It is useful for expectations and communication management, ensuring that it covers not more or less than defined in the project scope to meet stakeholders’ expectations. Similar to WBS, it helps the team members to have a clear understanding of their roles and when a deliverable is considered complete due to early definition of “done” for a deliverable. This boosts their confidence of project understanding, accountability, and transparency. (Dean Leffingwell, 2009). This also ensures that the development of the product has the right people involved and they are communicating together.
On the other hand, since it focuses on deliverables, there is a high risk of losing focus on how much details may be necessary to achieve the completion of a feature. It may be difficult to find a good estimation of deliverable decomposition to reach a “done” status. (Wettergren, 2020). Another shortcoming is that it fails to show dependencies between features.

So there it is, the discussion between advantages and disadvantages of WBS and FBS in the traditional project planning and agile project planning. What is your take?

Installing MySQL from Community Repository

One of the things that I often see experienced DBAs struggle with despite years of experience is MySQL installation in Linux. This is especially when installing from shell (Linux). This quick guide is intended to easen the pain of such installations and hopefully make everything straightforward. To begin with, log on to the server as a non-root user to reduce chances of overwriting a folder that you don’t have permissions on. Execute the folllowing commands thereafter:

#Change to the correct mysql version that you wish to install

1. yum install -y http://dev.mysql.com/get/mysql57-community-release-el7-9.noarch.rpm
2. yum makecache -y
3. yum install -y mysql-community-server mysql-devel mysql

And that is it. 3 simple commands that are straight forward but yet enough to cause endless headache, especially because the default MariaDb gets installed by defaul in Linux, if not correctly done. Cheers folks!!

Leadership – Expectancy Theory

Waterfall Model

This is one of the oldest software development models that was first brought to the limelight by Dr. Royce and has since been a point of discussion both in academia and industry. Although most development teams are embracing new technologies and development models, to accomodate change, should it be perceived that waterfall model is no longer important? Or is just the great fuzz that each company is going Agile without proper plans and preparations?

I

Personally, I find the model to be great and still practical even in today’s software development industry. It is the most underrated model even by people who have very brief and limited knowledge on how it works. It not only forms the foundation for the Agile model, but defines the kernel of software development. I must admit that it is not change-friendly especially when working with new domains or cross-functional teams. But it still contributes immensely to SW development, in terms of capturing stakeholders’ interests because alot of effort is put in capturing SW requirements in the beginning. It is a practical approach, especially when upgrading legacy systems and there is no time-pressure. Since the functionalities of the legacy system are already known, it reduces chances of changes in the latter stages of the model.

One of it’s weaknesses is that the stakeholders/PO’s only get to see the product in the implementation phase, which may be a bad idea especially if the product has not been developed as specified. I have often seen stakeholders who negotitate with development companies for a product, and then sit pretty and wait for the final product, only to be disappointed at the results. The KEY word is requirements’ specification, which again most teams have no idea what power lies behind it. As a stakeholder, if your valuable feedback is not availed during development, make sure you have a thorough requirements’ specification process. This should capture the product as you envision it, and help you relate the product to your expectations. Avoid pushing things to a later date and assuming that the PO captured your needs as required. Have a control check to ascertain that your needs are captured as expected. And as long as you are sure that this is not going to change, then waterfall model should be the best approach.

Looking at Agile, you quickly realize that it is actually a series of waterfall model whereby each phase is implemented in a Sprint. During this time, the PO locks the sprint and prevents any changes infitrating the sprint. This is not different from waterfall model, only that the sprint could be a shorter period. However, the idea is the same – mid-stream sprint changes are costly. Otherwise, it is till a very practical model in the industry even today and likewise it is used in university projects.

Change management

It is quite baffling how managers struggle with introducing change in their organizations and keep the changes permanently. Change is inevitable and is the only thing that does not change. Organizations expeience change eveyday, whether in their operations, management or culture. However, most of the times, the changes are short lived and soon everything rolls back to live in its previous status. I have met managers who didn’t understand why the company was unable to attain the set goals because “the employees were not embracing new ways of seeing things”, department heads who could not streamline operations to company strategies, developers who were stuck with the first generation of a technology that they learned while still in university and so on. What all these scenarios have in common is failure to manage change effectively. Managing change can be daunting, especially where there is no goodwill from management and the resources are scarce. But that is not a scapegoat, there are several change models that can be used to achieve the end means. Depending on the management model of the organization, some of the models that can be used to effect change include but not limited to Kotter change Model, Kurt Lewin’s 3 stage model, Orlikowski’s Imrovisational model and so on. An overview of what causes difficulty in implementing changes can be seen in the image below, copied from Knoster (1991).

In the next post, I will explore change management models, the kind of organizations they are suitable for and how they relate to each other.

Tools of decision-making as a manager

Making decisions in an organization is partly an art but also a skill that can be perfected over time. A quick recap one of my previous posts, where I explored decision making in organizations and the conditions necessary for making sound decisions. These conditions were named as evidence, authority and process. From the executive to the components and to employees, this is something that an organization should be keen to enforce in its company-culture. PMI advocates for the use of Code of Ethics and Professional Conduct to instill confidence in project management and help leaders make sound and wise decisions without compromising their integrity, PMBOK 4th Edition (2017). The complexity of decisions made in an organization scales with the management level in an organization. At the portfolio level, it is critical that the portfolio manager makes the right decisions when pairing projects to organizational strategies and choosing the right projects. As a project manager, it is also important that the right decisions are made in the management of projects. Employees should also make the right decisions when executing their job to safeguard the quality of the product or services they are working on.

To make a decision, one should evaluate on the nature and significance of the problem at hand. Programmed decisions are routnious in nature and are taken within the specified procedures. They are made with regard to

routine and recurring problems which require structured solutions. A manager is not expected to go through the problem solving procedures continously make programmed decisions. On the other hand non-programmed decisions are associated with unique problems that are non-repetitive. There are zero to very limited information and knowledge about such decisions. These kind of decisions are made under unfamiliar circumstances using new techniques. The standard and pre-determined procedures and rules are rendered ineffective because every decision will have to be taken separately. Such types of descions are meant for solving unstructured problems which keep on changing from time to time.

There are quite a number of tools and techniques that can be used in decision making that PMBOK suggests, which can come in handy. Some of the most effective and popular decision making tools include:

Cause and effect diagram: Also known as a fishbone diagram. It is very effective when the casue of a problem is to be found out In IT industry it focuses on the Big-5 M namely: Machine, Methods, Material (cosumables/information), Manpower and measurement.

Scatter diagram: This is a simple but also effective tool that is used at varying relations between 2 variables to support a decision. In case of investing how they relate, correlation may be deduced from such a graph.

Benefit/Cost ratio: An effective decision tool where finance is involved and there are alternatives. The benefits are calculated and divided with the costs. There is a coeffecient for each alternative and the one with the highest coeffecient is the best alternative. The problem associated with this tool however is that some benefits are not easily calculated such as customer satisfaction.

Histograms. These are used for showing a graphical representation of numerical data especially when there is need to view the number of defects per deliverable, a ranking of the cause of defects, the number of times each process is noncompliant or other representations of project or product defects

Some other effective tools include: weighted scoring models, Net Present Value, Opportunity Costs etc. As a project manager, the tool you choose and the method applied should be guided by code of ethics to improve transparency on the decisions made.

The agile project manager

Project management has today incorporated agility in it’s processes to help the project manager and the stakeholders to have better control of the processes and tools used. Organizations are demanding for better Agile practices that enhances the quality of the deliverables. A project manager has to therefore be willing to put some extra effort in the agile transformation journey if they are to realize any success. The most popular agile mindset used today in most organizations is Scrum, which is touted to encourage continual feedback, iterative development, rapid and high-quality delivery. Unfortunately, companies are rushing to be “Agile”, conducting morning stand-ups but do not actually understand how to go about the whole processes. When I was first introduced to Agile, we had our morning stand-ups and the whole team did not understand why the project manager was “Micromanaging the team” everyday. Most of the time Agile fails because the team is not well trained on what to expect. Some of these pointers are:

Missing discipline: When a team is not trained on the need to track stories, respect definition of “Done” and “Acceptance criteria”, being present on time during stand-ups and finishing tasks on agreed time, then the team will find it wasteful. These have to be adhered to and the project manager has to ensure that he provides the necessary coaching to get the team jump-started when they are slacking.

Continuous coaching: This does not necessarily mean coaching the team on the aspects already mentioned above, but also helping them to understand the business aspects of a project, keeping the inventory updated and addressing other arising team issues.

Absent or insufficient documentation: A project manager who does not keep documentation of anything, is digging the team’s grave. Though Agile advocates for value completed funtionality over comprehensive documentation, the project manager should remember that the aim of having a team is not just to deliver a project but also knowledge-sharing. This should cover technical specifications, test plans and functionality specifications.

Frequent feedback loops: The project manager should encourage rapid feedback loops from stakeholders to ensure that the product becomes stable and robust. Feedback that touches on modification of the project should however be added in the backlog, to be taken together with the whole team and also to prevent project creep.

These are some of the best practices that an agile project manager should ensure he practices to help the team be truly agile. So what tips do you use in your team? Kindly comment, I would like to hear.

Monitoring project progress as a project manager

As a project manager, there are numerous reports one has to file in, every time there is a project at hand. Actually, it is embedded in your work description and will be part of everyday activity. Whether it is reported in small or weekly bits, reporting is inevitable. Effective reports are able to convince the stakeholders to take action resulting in the project moving in the desired direction. One of the worst things that can ever happen in an organization, is to have lazy project managers who do reporting merely because they have to or have been asked to do so. The weekly report should not be made routinely without much impact. The team and the senior leadership should be able to see how the project impacts the strategies of the company and how it helps it realize its benefits. Poor reporting at times have led to candidate projects being denied funding or proposals being rejected.

Some of the most common mistakes that project managers make include

not being detailed enough about what the project details are. This denies the stakeholders the chance to understand the i’s and the j’s of the project. While reporting, the project manager should not only give account of what happened last tme and what they plan to do next, but should also indicate how this fits in with the project management plan, the risk management plan and how the roadmap leading to the deliverables look like. I have seen project managers write reports that you would have thought is a high school essay. Poor description with bare context and denying the audience the chance to get the information.

Thanks to project management standards, this can be done efficiently by following the steps below.

1. The project report while being kept simple, should at least add value by providing an overview of milestones, risks, issues and budgetary information.
2. The background of the project and why it is being undertaken is not and should not be included as part of the project. Remeber that this is execution stage and not initiation stage. The background should definitely be included as part of this report.
3. For transparency, the sponsor and project manager’s name should be included in the report
4. Reports can be boring to read especially for the senior management/executive who have less time. The port should strive to capture eveything in a single page concisely and clearly.
5. High risks that are a threat to the project should be captured, including mitigation measures under consideration.
6. Budget tracking and expenditure should be part of the budget. Is there something that will make the budget exceed beyond the exepcted amount, then it should be included as a risk instead.
7. An overview of major milestones, planned dates for this milestones and a RAG status of each milestone, helps the stakeholders to understand the project’s progression.
8. An evaluation of successes and failures should be included in the plan , to give an overview on recurring/resurgent problems so that the correct action can be taken. Successful projects can be marked for review and eventual learning to be used as a take-away.
9. In a clear and simple language, the report should note the action to be taken i.e. whether the report is for notification purposes or they are to be used for decision making.
10. Whereas it is fashionable to send reports by mails, it is a good practice to provide a summary in the body context of the mail. This is helpful especially in this current era where people use phones for reading mails.
11. Avoid sending breaking news/information on mail before communicating with the stakeholders. A mail on Monday morning about a server that crashed just hours before presentation can be demoralizing. Ensure the stakeholders are informed either face-to-face or by phone before ending mails.

So, which best practices do you follow as a project manager to ensure that the stakeholders are updated? I would love to hear.

Tasks delegation in project management

Delegating tasks in project management is a skillful art that is acquired over time. It is a tool that every ambitious project manager should have in their back pocket, if they need more work done. It is no longer news that as a project manager, one can’t perform all tasks, but can manage and coach their team to do the tasks. There will be never enough time to get the project done, but by delegating, the project manager gets to have more work done by the team and helps to keep the project within the timeline.

Being a team leader, the project manager should know how to delegate tasks, give support to team members and make the process a great experience. The project manager should not just delegate tasks and then disappear, rather they should be available to answer questions and specifics about the task delegated. They should help the team to understand why they have been delegated the task and what the results will mean. A

Courtesy of study.com

simple statement like “The results will be used by the portfolio manager to determine whether we should get more funding for project X” may cheer up the team, knowing that they are dependent on project X to create an impact on the business values. At times, though genuinely, it can be delegated by informing the team member that you simply rely on their expertise and there is no one else good at the job, that you could delegate to. It boosts morale, though it should not be said as a flattery excuse. The project manager should also avoid micromanaging the team after delegating tasks. It simply kills morale and is annoying. A one in a while follow-up is ok as it creates a rhythm for results expectations. An hourly follow-p and the next thing is a “sick” team member who can’t come to work.

As a project manager, one has to realize that their role is not about doing the same tasks they did before, rather they are supposed to provide leadership role. This means that there is expectation that the tasks one did before will most likely be done by another person in the organization. It is therfore imperative that the project manager develop a competitive team and learn how to delegate tasks to them. While the team is working on a task, the project manager should once in a while view the task from their perspective and understand that it is a learning experience for them. More responsibilities should be assigned and trust gained to help them grow. I remember when I started to explore Linux in the organization I worked for, I was the only one who had access to the servers. No one else in the company understood how Linux worked and I had the priviledge to be the pacesetter. It gave me the priviledge to come up with custom solutions and slowly learned the standard way of doing things. Today I am comfortable working in Linux, because of the trust I gained at that time. I coach new employees in Linux servers and ensure that they are allowed to mess up, though in the development platform.

A project manager while delegating work, should explain it to the team in a sufficient manner on what the task entails. Hinting does not work here. If not sure, don’t delegate the task, it leads to half done job, animosity and feelings of disappointment. The team on the other hand feels distrusted and untrusted or their competency ego may be bruised. Explanation should be done a t a higher level and if need be, then engage the key stakeholders in a meeting where the team can field questions to gain a better understanding of the task.

So, how do you delegate tasks in your team? I would love to hear.