Software implementation projects are not always straightforward. You set your deadline and budget, appoint the right team, develop a solid plan—and it all comes together. Right? Projects can run over budget, the team isn’t as synchronised as expected, the scope changes and ultimately the project doesn’t meet its initial expectation. As a project manager, you are ultimately responsible for delivering a successful project, so what can you do to give your project the best chance of success?
Traditionally, the Project Management Triangle has been a staple model to determine the overall quality of a project—whereby each point of the triangle represents a different project constraint. By successfully managing these three (often competing) constraints, it is theoretically possible to successfully manage a project. In reality, Project Managers need to be ready to accept that these three points can often move. See Figure 1.
Scope reduction may need to occur if there are hard Cost and Time constraints, and the project is slipping behind schedule. Cost may increase if Scope and Time are fixed, as more resources need to be allocated to the project. Time implications may come into play if Scope and Cost are constrained and either are not tracking as expected, as project redesign takes place and resourcing is shuffled. On the flip side, if all three elements are constrained, then only the business outcome can be impacted.
It is especially important to note that some flexibility is required to achieve a business outcome. So long as the adjustment is measured and well thought out, success can be attained.
The Extended Agile Triangle captures not just the traditional triangle, but also the quality of the product/service being delivered, and its value to the business—thus defining project success as “embedding a change within an organisation that achieved the desired business outcomes, whilst satisfying key stakeholders and learning from the experience.”
Nonetheless, navigating the triangles is difficult, but achievable. This article revisits recurring themes and observations through supply chain software implementations, categorised in four stages to best set up your project for success. See Figure 2.
The Prep Work
Planning is paramount to the success of any project, and the amount of required effort investment should never be underestimated, nor should it be hard-capped to a timeframe. A project which rushes into design and execution with an inferior plan is far more likely to experience rework than a project which spends an extra two weeks developing a solid plan. See Figure 3.
1. Support from the top
The impact of executive managerial support, or lack thereof, has a direct bearing on a project’s success—with one in three failed software implementation projects citing a lack of senior management involvement . Executive sponsorship and active involvement are crucial in ensuring that the project team, and those impacted by the project have assurances that the project (and its desired outcomes) are in line with the business strategy, and more importantly, have a positive effect on their individual day-to-days.
With executive sponsorship, there is a higher level of engagement, communication and accountability—all of which contribute to and improve overall risk awareness and collaboration. Sponsorship doesn’t just provide executives with an ear into the project, it sends the message “what you are doing is important.”
So how do we secure interest from busy individuals? It can be as simple as keeping them updated on developments outside of the regular (or irregular) Steering Committee cycle; asking for their input; and keeping a close working relationship with their direct reports. Additionally, subtle ongoing reminders of the benefits (not just to the business—but even directly to individuals) will assist greatly.
2. Identify your influencers
Within any project (or group of people for that matter), there will always be one whose opinion others will tend to gravitate towards.
Taking the time to have one-on-one discussions to build a personal relationship with your influencers will go a long way to embedding change within the organisation. By detailing the whys and hows, you will not only make that individual feel more valued, but it allows you a reference point in group environments: “So-and-so, what are your thoughts?”
3. Manage expectations
All too often, when the Go Live switch is turned on, you may hear a voice in the corner go “Oh, is that it?” All of this comes down to managing expectations—those of management, those of team leaders, and especially of those using the software day in and day out.
With supply chain APS implementation projects, there will be those who expect benefits from day one. From decreased inventory to service level improvements, workload reductions to full RCCP visibility.
When the go-live switch is turned on, it is important to note that:
- There will be an increase in inventory. Different APS software run on different methodologies. While the system will aim to balance inventory, orders will be recommended to address understocks, whereas overstock actions take time to conduct.
- There will be an increase in warehouse receipts. With a direct output of rebalancing and purchases for understocks, warehouse staff may be greeted with an initial surge of workload.
- System configuration settings will require ongoing analysis and maintenance. Parameters in-system require continual evaluation – status codes, lead times, order minimums are never set and forget levers. Manage your inputs, not your outputs.
- Not everything will be perfect. It is impossible to test for every possible scenario. Once-offs will occur, so it is important that these are addressed as soon as possible and does not derail the momentum gained at Go Live.
Communication is key when it comes to managing expectations. During the planning phase of the project, it is critical to calculate expected outcomes… not just the quantitative value, but also the timeframe—and clearly state any assumptions. During the course of the project, these expected outcomes need to be revisited, refined, and re-communicated. Prior to Go Live, impact assessments detailing the pre- and post- pictures are essential, as are subsequent reporting mechanisms to track against.
The measuring stick for success needs to be in your court—don’t leave it to others to decide. Manage the definition of success.
When it comes to solution design, maintaining a central repository for design artefacts is critical. Design encapsulates both the front end (how users interact with the software), as well as the back end (how data interacts and procedures and processes are sequenced), and the framework it sits on. A team that is well informed of the solution design is able to develop to tighter (and better defined) requirements.
In PMI’s yearly survey , it was found that 39% of organisations reported inaccurate requirements as one of the primary reasons for project failure. See Figure 4.
Additionally, organisations classed as ‘champions’ far outperformed those classed as ‘under-performers’ when it came to projects that met their original requirements (92% vs. 33%).
4. Tight configuration control
At first glance, between all the Functional and Technical Specifications, System Architecture Definitions and Process Flows and Interface File Policies and Configuration Templates, it may be seen as over-documentation, and project overhead. If managed incorrectly, this is definitely the case. If managed correctly though, it provides the project team with central reference points, and design SMEs (Subject Matter Experts) to confer with.
(i) up-to-date documentation
Decisions must be documented. All too often, undocumented changes result in confusion during the development and testing phases, due to a misalignment in expected results.
On the minor end, a simple undocumented screen layout change may result in configuration scripts not being updated, which results in a rebuilt environment differing to what a user would expect. On the more serious end, an undocumented architecture change could result in the rebuilt environment not running all at (incorrect certificates, incompatible plug-in versions, etc.).
Even something as small as a calculation change may cause distrust in the data. This causes great amounts of nervousness when detected close to Go Live, and even worse if detected afterwards.
(ii) Version control
A lack of version control management is the bane of Configuration Control. Instances where a single ‘live’ document is used throughout the life of the project does happen. This must be avoided.
Project teams need to get into the habit of using a standardised method of version control. Similarly to software, documentation can be managed via both ‘dot’ and ‘full’ releases – dot releases for incremental updates, and full releases for milestones. The updater does not need to create a new version for each individual update (i.e. V1.02: “changed field XY to blue.” V1.03: “changed field YY to red”), but they need to keep to the mantra: “if I need to send it to someone, it’s a new version”.
Not only do decisions require documentation; they require communication. Be selective with your recipients too—the entire project team rarely requires each update to each document, only those whom would fit on the RASCI.
Email as a traditional medium is often sufficient. However, with larger project teams, other tools may add more value. Even if you can’t get access to top-end tools such as Rational ClearCase, tools such as DropBox are more than enough to house prior versions and communicate active versions.
(i) This article continues in the March-April issue of MHD Supply Chain Solutions magazine. Read Giving your Software Implementation the best chance to Succeed - Part 2
(ii) This article was published in January-February issue of MHD Supply Chain Solutions magazine.
GRA Manager, Nathan Singhavong, specialises in software process design and analysis. He delivers supply chain process and software solutions across the commercial, defence and government sectors.Download – PDF (4.3 MB)
Reproduction of GRA whitepapers and articles
GRA permit the reproduction of GRA authored whitepapers and articles so long as all the following conditions are understood and met:
- Entire credit details must be included:
- Author's name(s)
- GRA name and contact details
- GRA URL link to the original article
- All hyperlinks within the article must also be retained
- Articles must not be resold
- GRA retain full copyright.
If you have any queries about reproducing a GRA article or whitepaper, please contact GRA Marketing