2022 Five Common Pitfalls for Your Upcoming Project

Key Risk Areas for Project Failure

There are many different pitfalls one can run into during a project. Depending on your field, there may be differences in these common issues. Some of the most common pitfalls that we see in our industry are:

• Solving the wrong problems or not solving them efficiently by taking on a lot of work that may not meet the customer's needs.
• Attempting to do everything at once versus focusing on high payoff activities will give a Pareto's Principle type of model, eighty percent of the results for twenty percent of the effort and resources.
• Being able to define the scope of the project clearly and the scope of the work that is going on. So that everyone's clear, there's an exact goal post, a clear deadline, clear metrics for completion.
• Define the project, identify key risk areas, and then work through those key risk areas. Ideally, mitigate those immediately or quickly during the timeline of the project.
• Not taking the people side of it seriously enough or adjusting the model to account for the people side is typically the number one cause of pitfalls. Ensure the essential responsibilities, qualifications, and accountability are aligned. There's essentially ownership within the project for delivering and resolving issues and being accountable to the end customer and the project's end goals.

It is all too common in the rush of business and the rush of executing to lose sight of what needs to be done. Many of our clients focus on unintentionally myopic views that tend to be self-reinforcing within their team. These views might be somewhat or significantly accurate, but they may be missing the full picture. They might be missing the client's perspective by only talking with a few very vocal clients. So, they end up unintentionally gold plating something that isn't necessary while leaving rough edges on a vital part of the process.

So, how do you solve the right problem? The best thing to do there is to take a step back with your client and understand their customers' needs. Often, we see clients who don't have a lot of experience, haven't operated business for a long time, or maybe haven't gone through a significant software development project before. They may not understand that the best move is to understand the customer's needs. Spend time talking with them, holding meetings with the internal team, and analyzing and critiquing the plans and ideas.

The importance of competitor analysis cannot be understated. Look at competitors' software, look at what is available in the market space, and validate whether or not the area that we're working on at least meets or exceeds what is competitively available. Ensure that they will benefit from some of these capabilities when we're talking with clients and customers.

So, how do you solve the right problem? The best thing to do there is to take a step back with your client and understand their customers' needs. Often, we see clients who don't have a lot of experience, haven't operated business for a long time, or maybe haven't gone through a significant software development project before. They may not understand that the best move is to understand the customer's needs. Spend time talking with them, holding meetings with the internal team, and analyzing and critiquing the plans and ideas.

The importance of competitor analysis cannot be understated. Look at competitors' software, look at what is available in the market space, and validate whether or not the area that we're working on at least meets or exceeds what is competitively available. Ensure that they will benefit from some of these capabilities when we're talking with clients and customers.

Foster a healthy dialogue with them by setting up conversations with both customers and internal team members to step back and ask questions about their needs. These needs could be automation, quality of life improvements, or features from other sites and resources they think would apply within this business. Essentially, getting an honest and direct conversation with those folks and ideally getting them to share what they feel whenever they look at the current system or what they have available to them.

A lot of times even really helpful to have external resources for reviewing their project. Many different companies offer uninformed audiences to review the current infrastructure, software, website, and web application. They can review the process and share what they're thinking. They get paid to do this for a living. They go through the site and critique it. It's what I would refer to as friendly critiquing. The idea is they're coming at it with no vested interest, which in many cases is very helpful to be able to understand the real issues.

So again, to emphasize, a lot of times, the Pareto's Principle applies. Major glaring issues require a relatively minimal amount of time to dramatically improve the overall effectiveness, usefulness, and even the credibility of your website and the user's experience.

Attempting to do it all at once is a widespread thing within software development and entrepreneurs. In corporate scenarios, clients will often focus on doing "all of the things" versus doing the things that we do very well. There's a significant distinction between those two approaches. The focus on software will dramatically improve the results by focusing on doing the things we are doing very well. In other words, being willing to make it a priority to focus on quality, quick delivery, and getting feedback and information back about the usability of the software. It's not as much about delivering all the features perfectly. It's about delivering usable incremental improvements and additions of features that you can quickly get feedback on and then iterate on.

This model of focusing on an agile development process tends to create a focus and a lot of credibility around the idea of the company listening and being open to feedback. It creates this very healthy dynamic where people, customers, and internal team members see that things change whenever I make a suggestion. It's not always perfect, but it is much better than it was based on the feedback. It's the stuff that makes sense that is making a difference.

Typically, the software is very complicated, depending on the scope of work. So, having the ability to build a culture and thought process around an agile development cycle, we're always making updates that are usable and units of work that you can get feedback on. That's key to being more efficient and ultimately more effective. Because again, if you go back to solving the wrong problem a lot of times, if you build a bunch of software and do a lot of work, but it doesn't solve the right problem, you're wasting a lot of resources even though that work might be done and done well. Unfortunately, even though you might take time to discuss and review with folks, ultimately, you're not going to know for sure if something is highly usable until you get it deployed and get feedback.

So, the name of the game is to try to focus on the very best thing, try to spend enough time doing the analysis, and then break that very best thing into units of work that you can then get validated as you go. It's just a feedback loop that the shorter you make the feedback loop timeline, the more effective that feedback loop is.

Clearly Defining the Project Scope

It also makes sense to point out that this ties in tightly with finding a realistic scope. Defining a practical scope to articulate and document an actual definition and specificity to the units of work that are happening. Having this granular information, you can put a plan together with the vision of a bigger context than just a small unit of work. So, with the future in mind, you've got to break the work into small chunks to be able to get the feedback and be able to roll things out successfully

Often, software complexity goes up in orders of magnitude whenever you add additional significant features that have to be compatible with already implemented features. When you're in development, it's best to work in milestones with units of work. These units of work could be three to six months long before you make a release. Afterward, you would deploy another unit of work that might be another three to six months long if this is a larger project. If it's a relatively small project, you could deploy an off-the-shelf eCommerce and integration platform with minor customizations. Within a few months after release, we would roll out relatively significant customizations as updates that match the business needs.

Breaking the work into chunks improves the whole process's efficiency and helps clarify the scope. For internal purposes, it can be helpful when you're working on a large amount of work to break it into identifiable units of the total scope and clarify the scope enough with detailed documentation and design specifications of what the requirements are. Ensure that the work is reviewed during the development lifecycle to ensure an internal feedback loop throughout the project's lifetime.

Suppose the business is confident in doing a lot of work internally to complete the project. In that case, it will want to do internal reviews, audits, and feedback loops consistently in the agile type model. To do all of this, you will need some skill level for each work unit and have a clear vision of the project. The document that vision into a clear scope document with compositional designs and detailed specifications. This documentation will be frequently updated as the feedback loop progresses.

During a project, it's not uncommon that areas of the project will change based on potential key risk areas that we've identified. For example, we may need to use a specific plugin or external provider because of potential security risks with an existing solution. Threats such as these and many more can be found throughout a project. Using an agile model where we're iterating on chunks of work, it's possible to mitigate many of these risks.

Knowing that these applications are complicated and may not always be compatible, we'll recommend identifying potential risks and mitigate these areas by completing test scenarios. The assumption may be that this is a very bare metal, unsophisticated validation work to be completed. Still, these use cases are necessary to explore what the technical capabilities are for integration or if we need to sign into a third-party system.

We may need to do a basic implementation with a third-party system with some manual steps that won't be automated. We will want to spend four to eight hours manually validating that everything should work correctly. It is essential to do manual validation to identify critical risks and invalidate the different workflows and integrations that open the system to threats. When integrating with third-party software, some of the capabilities and functions in place may not always be clear. Once you start the implementation, you start to realize where some of the limitations and unknowns are. Ultimately, any unknown can be a problem for the project as a risk, and anything that is a known risk will be validated and removed that risk.

Finally, one of the essential things on a project is recognizing that the real producers and problem solving on a project is done by the teams working together. It's typically a composite of internal and external team members collaborating to form the comprehensive project team. It's critical to know when working on a project who's in charge of what and who owns what. For instance, the internal, client, and external providers all talk to each other and understand what each person's group roles are, each team member within the respective groups' roles, and who's in charge to ensure that everyone's on the same page.

It is fundamental to have clear guidelines on everyones' role on the project, but getting that to happen requires planning, discussion, directness, and the ability as a group to build a standard set of objectives around completing the project.

What's more critical than anything else is the ownership each of the groups has and the form of accountability that comes with it. It's essential to have the discussions upfront about who owns what, what the accountability areas are, and what commitments everyone is making. Clearly defining ownership helps facilitate, with all of these potential pitfalls, and we come to the table with a framework that has been proven on hundreds of past projects to be successful.

Typically, we recommend breaking your project out into pre-implementation, post-implementation, and support ongoing enhancement phases. Many times if it's a large project, we recommend splitting it into smaller milestones. We will gladly bring our framework that we've used successfully on hundreds of projects to bear with you and collaborate with you to make sure you're comfortable with it. We make any changes or revisions that match your team dynamic and your business so that you can be as successful as possible with your upcoming projects.