Throughout my career, I have seen projects big and small lead to great successes and less-than-ideal outcomes. In fact, one memory that has stuck with me throughout is that of my very first job straight out of college. The year was 2009. The firm that I was working for at the time had embarked on a multi-million dollar project that was intended to function as a catchall for customers, back-office, trading platforms, Sales, Service & everyone in between. Despite being built offshore & managed by the senior staff here in New York, the project was 2 years late and several million over budget. Frustrated by the lack of progress, one of the operations managers allied with the head of Sales & convinced the COO to buy Salesforce licenses. While promising, Salesforce sat on the shelf for almost a year as the firm lacked the expertise & bandwidth to customize & roll it out. As a young developer, I saw this as my opportunity and quickly took up the baton. In months, not years, we had customized the platform, integrated the website & trading platforms with Salesforce. We finally had marketing, back office, sales & service up & running on one platform.
Every project has a different definition of success but the goal is always the same – to improve performance. During my career, I have been a part of hundreds of initiatives ranging from minor optimizations to creating infrastructure from the ground up as well as complete stack overhauls. I would like to share with you my insights on the characteristics that lead to successful projects.
Dream Big, but walk before you run & crawl before you walk.
Embarking on a project, especially a digital transformation is often an exciting experience that brings out the entrepreneur & innovator in all of us. However, if you want to be successful, you need to approach each project methodically & strategically. It’s often helpful to have a long-term big audacious goal in mind but break it down into measurable and attainable milestones. It should often start with an MVP – Minimum Value Product that ties back to a fundamental step in your long-term roadmap. State your criteria for long-term success and work backward to deliver its most fundamental elements. Then build on it. It’s how houses, cars, molecules, cells & virtually everything in life are constructed.
Unless you’re in product development, buy, don’t build.
Just think back to that first project I spoke about earlier. In that example, the company was a broker-dealer – not a product company or CRM developer. As such, it is no surprise that building a CRM from scratch turned out to be a failure. I’m an engineer so I get it. Sometimes, there is nothing that fits exactly what you’re trying to do & that’s ok. Just don’t start from scratch. Always build your architecture in a modular fashion where pieces are interchangeable but closely coupled. If what you want can’t be done out of the box, find something that comes close & customize it.
This is what makes Salesforce such a powerful tool as a foundational element to an organization’s tech stack. While it is often thought of as a CRM, one of the first things I like to remind my clients is it is as much a CRM as it is a Platform As A Service. Even when building a vanilla website or App, frameworks are leveraged to abstract much of the repetitive & fundamental aspects such as security & content management. All your Projects should embrace such principles. If you find yourself building something that a major company already does & you don’t intend to compete with it, stop & think carefully about the path you are about to go down. It can be a lot more painful & expensive than you think.
Spend the time to plan out your roadmap. Be flexible & revisit the plan often.
Take the time to plan your vision. Put it on paper, socialize it & don’t let it grow stale. Often, we find ourselves rolling up our sleeves and diving in to solve the problem at hand without the bigger picture in mind. This can be one of the largest sources of failure for projects. Whether it’s executive demands, tight timelines or impulsive stakeholders, jumping in to build without understanding and documenting the larger context is almost always a recipe for failure. Worse, that failure will often not become apparent until much later when you realize the foundation that was laid is faulty or incompatible with your organization’s long-term goals.
Once you have laid out your blueprint, don’t assume the planning is done. Successful companies & projects revisit & revise their roadmaps often. Lots of things will change for a variety of reasons but following the blueprint will help ensure everyone is rowing in the same direction & increase the likelihood of success.
Don’t skip documentation.
As a firm, we will often be flexible with what our clients want. Some want novels upon completion of a project & others don’t see the value in the documentation at all. As previously mentioned, planning is pivotal for customer success. But what’s a plan without documentation? Just an idea. Documenting brings your ideas to life. A huge element of project success is documenting before building. Working off a blueprint helps ensure a mutual understanding of goals & requirements. Documenting the technical side of things upon build is equally important. It helps ensure the quality of build & continuity for future enhancements.
Don’t underestimate your time.
Be prepared to commit a significant amount of time and internal resources to ensure a project is successful, especially if you are outsourcing a significant amount of work. Folks often look to consultancies to drive projects end to end & of course, that is our job & we strive to deliver perfection every time. That said, nobody knows your business better than you & your stakeholders. Before embarking on a new project, make sure you have the right people and bandwidth to support the project’s success. Discovery & User Acceptance Training (UAT) are two areas where significant bandwidth and interaction from multiple stakeholders will likely be needed. Successfully flushing out requirements in Discovery & ensuring UAT has been exhaustively completed are absolutely critical to a project’s success.
It takes two to Tango, but three is a crowd.
Projects often have multiple stakeholders that create a center of excellence to help ensure outcomes align with goals. The key to success however is to select 1 individual from each side who is primarily responsible for the success of the project. That can mean planning, budget, requirements, acceptance, or any combination of the above. They should function as the coordinator to ensure buy-in from all the relevant stakeholders but there should be just 1 person who is ultimately accountable for success.
Having multiple primary contacts can lead to requirement ambiguity, contradictions & diffusion of responsibility. That last part can be especially devastating & arise despite the best of intentions. When more than one stakeholder is responsible for the same task, they can often make assumptions about the other’s intentions and involvement which can lead to balls being dropped and key requirements missed.
Make sure you select the right person to run the project.
Entrusting a single individual from each side as primarily responsible for the success of the project is important. Making sure that the person has the requisite skills to assume that role is even more critical. If it’s a technical project, make sure the stakeholder is technical and capable of understanding what needs to happen & the decisions being made.
I can’t stress how important this is & how many projects I have been a part of that went south due to the stakeholder’s direction & poor decision making. As a consultant, I always feel responsible for any project that doesn’t succeed and there is nothing worse than driving towards a goal that doesn’t ultimately meet the organization’s needs.
Beware the Ides of March. And IT staff who feel threatened by innovation.
The least satisfying part of my job is often automating away jobs and/or replacing antiquated systems the results in tech downsizing. Unfortunately, progress is necessary and this is often the consequence. I sometimes think about the future & the tech that will automate away the value I bring (I’m looking at you, Einstein & Watson). Nevertheless, we must always strive to do what’s best for our organization & those we serve. Unfortunately, sometimes you meet resistance to change often in the form of current staff or contractors who view the project as a threat.
I am not sure if “surprising” is the right adverb but this happens fairly often & you must always be on the lookout. While this will often manifest itself as benign protests such as missed meetings or apathy, I have seen what I can only describe as active sabotage as well. This can take the form of intentional actions such as providing poor guidance or data. Even if intentional acts aren’t the primary impediment to success, subconscious protests such as indifference can lead to project failure or massive misalignments in scope. Be especially aware of the “I can build this” disgruntlement. It’s not that they can’t, it’s just often the case that they shouldn’t. One guiding maxim I often advocate is to leverage existing technology where you can as often as you can, in as modular a way as possible. Unless of course, you want to end up with your own “Portal”.
You generally get what you pay for.
I have certainly seen value delivered at lesser prices but almost exclusively when driven by talented & expensive senior staff. Absent such a configuration, expect disappointment. Missed deadlines, poor understanding of business requirements, poor analysis & design are usually par for the course. Folks often find huge price disparities between on-shore & off-shore services that leave people questioning the value of the work being produced & contemplating if it can be done elsewhere cheaper. What often gets lost is the opportunity cost of delays, rework & poor design. Most importantly, if you accept my previous statement that a project is never truly done — the foundation created by cost-cutting measures will often lead to a reliance on the same technologists to maintain the mess they created.
The cost of technology implementation is often 50-60% Planning, Design, Project Management & Documentation. The rest is the writing of code. If you have the talent & bandwidth to take on the design & management aspects of a project then by all means explore cheaper options for implementation. If however you require a greater degree of assistance, either do it right or don’t do it at all. It will end up costing you more in the long run. Reach out to us to learn more!
