5. Lock Down Architecture & Processes
The importance of stable infrastructure throughout the project cannot be underestimated. Key to establishing a stable baseline are well defined requirements and processes. Without adequately managing both, two dreaded words will begin to be uttered: scope creep’, which is attributed to 41% of project delays
(i). Requirements Definition
Time invested up front in defining requirements and communicating the outcomes with project stakeholders is essential to minimising the risk of scope creep. At the very minimum, the following documents should be established and referred to as the baseline.
- Who are the key stakeholders?
- What is the strategic intent and rationale?
- What are the goals and success criteria?
- What are the assumptions and broad approach?
- How the user will interact with the system, and what tasks they expected to undertake and expected outputs?
- What data feeds are required to support reporting requirements?
- How will the functional specifications be achieved?
- What software/system requirements are required to support this?
Of course, these are not the only documents required—but baselines will act as inputs to all others, i.e. budgeting and schedule, risks, UAT, etc.
(ii) Process Design
Equally important in being able to lock down architecture is understanding the interactions between users and systems, systems and systems, sequencing of events and the flow of data.
A nice method to discerning what the future state should look like is to model the as-is state—and then overlaying requirements on top to create the to-be state. Not only will this provide the delta between the states, but it will provide a holistic view which can then be re-sequenced or optimised. This then provides the base to review and refresh business processes, procedures and policies. Be prepared to develop and look at many process maps.
(iii) Establish Architecture
With baselines on user, system and data flow requirements, architectural design can take place. A sufficient arrangement consists of three isolated and identical configurations.
- Production–the environment where day-to-day business processes are operated on
- Test–an environment reserved for test datasets, and verification of developments; ideally set up with the same frequency of operation as the Production environment
- Development–for on-going development work, with the ability to synchronise from either the Production or Test environments for impact assessment and outcome analysis; ad-hoc run
A stable base across environments will provide the ability to conduct like-for-like stress testing and outcome expectation. The rebuilding of environments is often a time-consuming and expensive exercise—hence the importance of design and process baselines.
Figure 5. Key peripheral documents and outputs revolve around three scoping documents.
After all the preparation and planning, the amount of resource investment extrapolates—making it all the more important to adhere to baselines and keep configuration tidy. On-going unit testing and larger testing milestones also become critical to the success of the project.
Figure 6. Potential workflow utilising three environments to minimise disruption to end-users.
Test Plans and Specification documents go hand-in-hand. Every requirement needs to be testable. Every test needs to cover a series of scenarios. And every scenario needs instructions detailed, datasets prepared and expected outcomes defined. Of course, we don’t know what we don’t know, so not every single scenario and outcome can be tested for—but the risk to the project is most definitely minimised by consistently asking “How do I test this?”
Equally as important as UAT documents is the owner. The owner must be able to drive developers and users alike to cover off all test levels, and act as the medium to escalate risks and issues.
Figure 7. V-model:linking requirements to tests.
7. Dedicated testing/training sessions
Testing is important, it can often occupy up to 10–15% of a project’s schedule. As such, one of the difficulties faced lies in freeing up resources to dedicate periods of time to UAT. A survey had found that two-thirds of UAT testers found time to be a pressure point within projects, often because day-to-day duties could not be left alone.
From experience, in instances where dedicated rooms and sessions were established for testers, and fill-ins used to take over their daily duties, testers not only achieved a higher UAT completion rate, but their understanding of functionality and aptitude of the new tool(s) was significantly higher than those who were still tied to their day-to-day tasks. Not only that, but being away from all other distractions allowed the testers to bounce questions and ideas off each other—and a sense camaraderie is built.
Moreover, testing can never be rushed—and should take as long as it takes. The last thing you need is a live product with defects, due to inadequate testing.
This same approach is not only restricted to UAT, but also applies to brainstorming, requirements definition and user training sessions.
Remember that distractions and focus share an inverse relationship.
Figure 8. UAT testers point out that time pressures often lead to poor UAT outcomes.
8. Keep the environment open and inclusive
Project fatigue is real. As the project runs, team members can lose their enthusiasm. However, there are always opportunities to keep the environment feeling less pressured and more upbeat. Communication plays such an important role, not only for project updates, but to build a connection with project team members on a more personal level.
Try to keep large meetings to a minimum and keep invitations strictly to those who need to be present to make some form of decision. Aside from the scheduled project meetings, having an open environment and providing team members with opportunities to speak up will result in a more productive and cohesive unit.
Often times, doing the small things will reap large returns.
(i) Reminder of the (grand) future state
During periods where enthusiasm slows, it’s always a good move to remind the project team of what the future state is, and how far it is from the current state. Recapping the benefits will reinvigorate the team.
(ii) Celebrate Milestones
Milestones are to be celebrated! It provides all those involved with a ‘thank you’, and energises the team to get to that next milestone. It also can have the effect on those on the outside looking in to want to be a part of the team.
(iii) Acknowledge Personal Efforts
Aside from team successes, personal efforts are not be forgotten. From public acknowledgement to physical gifts (i.e. gift cards), any form of recognition is always well received.
(iv) Talk to Team Members
Another effective medium is a quick catch-up outside of the work environment. Taking away the sounds and sights of the office is a reliever—often leading to concerns being aired, new insights developed and more importantly, it makes team members feel valued.
Success is not just about completing the project or task— it is taking something out of it and being applying it to the next one.
9. Knowledge Transfer
Prior to the project, business and process champions will have been identified. During the project, these nominated champions will have been up-skilled to become SMEs. But what happens after the project? Their roles should never end.
Your champions should be responsible for the up-skilling of the members in their respective departments and need to lead by example. Additionally, your champions need to be on point to evolve the processes and tools as the business evolves.
From a project management perspective, taking the time to reflect and conduct (and document) a Lessons Learnt session before beginning a new project/task is important. Not only will it allow for some much needed downtime after the project completion, it allows the senior project team to gather their experiences, and ask “how could we do it better next time?”
Remember that project success is never dependent on the person leading the project, nor does it depend on the project management philosophy adopted.
Rather, it is a mix of learning from prior experiences, from each other and being open to collaboration. Sometimes, the best idea in the room is not your own.
Allow others to be creative, and don’t be afraid to challenge, or to be challenged.
(i) Part 1 of this article was first published in the January-February issue of MHD Supply Chain Solutions magazine. Read Giving your Software Implementation the best chance to Succeed - Part 1
(ii) Part 2 was published in March-April 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 (2.4 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