During our experience, we have identified that both IT experts and project sponsors use natural language to discuss, both parties being absolutely convinced that they understand each other. As we have seen it many times, this doesn’t seem to have the expected outcome.
Thus, as a result of our consulting phase, we brainstorm research and collaborate closely with project sponsors to craft practical deliverables: Visual representations of the product and business flow and SRSD ( Software Requirements Specification Documents) that we consider to be the “Constitution” for the development phase.
Being agile, in our collaboration model we though of including our project sponsors in each intermediate demo, making sure that feedback is provided and included in all stages of the project.
We have learned that is may be impossible to control the changing project objectives, but it is possible to minimise the impact of shifting objectives by working in a model that supports change when required.
Changing the project objectives represents the blame for 36% of failed projects, but changes in the plan don’t have to lead to failure. We minimise the risk by reducing the timeframe of plans. For this, we put a great deal of effort into the analysis phase to make sure we have the “Constitution” ready. The consulting effort continuers through the implementation phase, where we act as spalling partners, as we provide input in regard to the project’s business flow, we innovate and keep a close relationship with the project sponsors.
Estimates, as variable as they may be, are a necessary evil In IT projects, because few business sponsors are willing to hand over a blank check. As consultants, we are transparent and we know we need to work with project sponsors to get a fair split of the risks. As part of our consulting process, we propose a fixed priced analysis phase ( where we take the risk of having a loss) but we only commit to a budget once the SRSD, Mockups, technology stack elicitation, dependencies and project objectives are clear.
A major pitfall in the software industry is that team rely only on the inputs of the one designated as the project sponsor and completely ignore the fact that the software will impact a lot of other people. As part of our consultancy, we consider all the people impacted by the software and we conduct interviews, discussions, brainstorming sessions with all the people that are identified as possible stakeholders. We do this to ensure that the product vision is complete and we have taken into account all its uses, allowing them to excel rather than having to use another tool as complimentary to make their job/life easier.
Therefore, our “unique approach” is ensured by our experience and passion for what we do, and the outcome of this is seen into our consulting processes:
- Project analysis process -> deliverables: stakeholders map, SRSD, Mockups, Technology stack, High Level Estimates;
- On-going consultancy during Development phase -> deliverables: Innovation, Demos, Status check with all stakeholders, Delivery Management;
- On-going consultancy during Maintenance phase -> User Behaviour, Improvement plans, Security Updates, New Functionalities Proposals.
These suggestions are based on an Organisational / Operational diagnosis and on a Technical diagnosis: SRSD – Software Requirements Specification Document or a Product Map.
Our expertise allows us to solve solutions in one of these areas:
- Organisational: Management & Structure, Growth, Financials, Operational Capabilities or Processes
- Technical: Software or Product Development, Internal Systems