In working with clients for over twenty-seven years, VL OMNI has had a lot of visibility into the frameworks of project management. We’ve seen clients lean heavily on project management practices while others don’t consider it at all. One might think those clients who prescribe to project management methodologies would find more success in their projects, but that’s not always the case. In fact, sometimes it’s the project management process itself that runs the risk of missing critical milestones or launch dates.
Put another way, very few companies actually follow the core project management ethos. More often than not, what is called project management, is really just a loosely defined schedule, high-level tasks, and someone to check the boxes when items are completed. Beyond that, there’s no alignment with actual project management processes.
In 2017, a study by Olivier Mesly suggested that the success of any project depends on how well four key aspects, referred to as the four P’s, are aligned with the contextual dynamics of project management professionals:
Plan: The planning and forecasting activities.
Process: The overall approach to all activities and project governance.
People: Including dynamics of how they collaborate and communicate.
Power: Lines of authority, decision-makers, organograms, policies for implementation, and the like.
Beyond this very high-level view one also has to consider what’s called the triple constraint in which a project gets to prioritize two of the following three items:
So, for example, you can complete a project quickly at a low cost and the quality will suffer. Or, focus on time and quality which will inevitably make the cost go up. How you prioritize each of these will impact the other two.
Then, after all that, you still have to contend with things like Gantt charts, resource management and even project management software in order to bring your project to a successful finish. Furthermore, any or all of these may be part of one of nine “flavors” of project management, each with their own benefits depending on the type of project you’re undertaking. This certainly sounds like a lot, and it is.
Committing to project management takes an enormous amount of dedication to specific processes and following through on them. For many companies, this can be a challenge while trying to manage the day-to-day operations of the business. This being the case, it’s no wonder most companies only practice project management in name only. Most of the under-the-hood processes that make managing a project efficient are never really followed; then, all too quickly, your project management becomes problem management.
All that being said, how does a company successfully manage a project without the discipline to practice necessary principles? Well, for better or worse (depending on your experience), project management is an optional and pure force of will can be a powerful driver. While following the purest form of project management may not be attainable there are key areas in which you’ll gain some of the benefits without going all-in on the methodology.
If you go online and do a search for “project management failure” you will find a high number of articles discussing what causes a project to fail. This can include a number of key areas but the one that comes up most often is communication and/or discovery. The time before a project even kicks off and plans are still underway. Projects can be exciting to work on.
It’s the shiny new thing everyone wants to get up and running. However, this zeal to get things working can become a detriment when the Discovery process is rushed or not done at all. Rest assured, of all tasks involved in a project, the information-gathering phase should be given the most attention.
To avoid project failure, what this really boils down to is minimizing the overall unknowns about a project. Discovery should be a no-stone-left-unturned process. When implementing a new integration in real time, it’s very important to make sure the new thing will be aligned with your existing business processes or technology stack.
The Discovery process should provide, up front no less, all the information necessary to complete the project goals. Moreover, it’s the project phase in which the majority of context should be coming from the client, not a technical partner. As the business owner, clients will have the most to provide in the way of how things need to work. Technical partners, by comparison, simply won’t have the level of institutional knowledge to put the entire solution together.
The more information you have up front the better managed the project will be. It sounds simple enough, but there are some other necessities that come in the way of project resources (all the people working to bring to fruition the overall deliverable), specifically skill sets:
Technical Expertise – People who can speak to the client’s technology stack
Communication – People who can provide clear, concise, and complete instructions
Business Process – People who understand how internal processes work
If you take all that into account the Discovery phase excels when you have people who are:
Highly knowledgeable the business and technology
Highly effective communicators
The importance of having people who exhibit these traits cannot be overstated; their foundational information becomes the backbone of the project. The better, and more detailed, your Discovery the better the project requirements will be and also minimize re-work later on (which in turn often leads to going over your budget).
Here’s the thing about timelines, they always change. Through no fault of our own external forces will often impact a project’s timeline and dates need to be adjusted. We see this all the time.
It’s not enough to expect timelines to be altered for one reason or another, you actively have to plan for it. Not only that, in most cases you’re actually managing three or more timelines depending on where the division of labor resides. This will vary from project to project but in VL OMNI’s case we often have three primary stakeholders on any given project:
- The client (or the business who is requesting the work to be done)
- A design partner (the team working on the front-end of the online store)
- An integration partner (the team working on the back-end of the online store)
Almost without fail when a new project commences clients start asking for timelines. This isn’t a bad thing, but it can be a very misunderstood thing. From the client’s point of view they think the timeline looks like this:
Basically, all work to be done is on the same timeline as the client’s work. However, this is how one should consider the timeline:
In this second iteration, you can more easily see how each stakeholder is part of the timeline to complete the project. We can even take this a step further here and flatten all the tasks into one shared timeline:
In this third timeline iteration, you begin to see how all three timelines are dependent on one another and there’s never actually one “client timeline” at all. All three stakeholders are part of the timeline, each with differing requirements and needs.
Much like the Discovery phase discussed above, Testing is also an area that can often be ignored entirely. We get it: You’ve just built this new thing and you’re so close to taking it to live, who wants to do boring testing? Well, everyone really would want to do this.
Typically VL OMNI allocates two weeks for testing, but it may take more time depending on the complexity of the integration that has been built. Much like the Discovery phase this is an area that should involve the client extensively. In fact, we ask that clients do this testing themselves (e.g. create orders on their online store) because they’ll have a far better understanding of the operation of the store going forward.
Testing really comes down to two key areas:
Making things break
Confirming what is working
Of course, the “making things break” part is a little facetious but kind of what we want to do. This is the time to make sure the integration process is working as it should but also test as many edge
cases as possible. Only by testing and confirming will we be able to make any adjustments to the integration and make sure everything is working as designed.
As in the Discovery phase, people conducting the testing should be well-versed in business processes and how customers will engage with your store. Testing, in part, is replicating the front-end journey of a customer but also how internal teams (e.g. Customer Service Representatives) manage the store on behalf of customer requests.
The takeaway from all this is that Project Management can be an all-encompassing initiative and not all clients will have the resources to take it on. However, even by just following the key areas noted above your company will be far better positioned to complete a project on time, and on a budget which results in an overall seamless customer experience once the project is complete.
Having successful phases of Discovery, Timelines, and Testing on your data integration project is a team effort that must be shared equally between the Merchant and the service provider. In order to get the most out of your integrations, adequate attention must be paid to all three phases of onboarding with the whole team taking accountability and ownership of the project.