The requirements are done, the vendor is selected, and the project kicks off. Once you’ve gone through the RFP process, secured funding, and selected a solution and/or vendor for the mobile enterprise project, you’re ready to get started right? Not quite, there’s still one more step, and that’s to get everyone on the same page.
This is easier said than done as you’ll need to involve both internal, and often external, experts covering areas such as:
- Business knowledge
- Backend/existing systems
- Network communications
- Infrastructure/Server teams
- Security, fraud, risk teams
- Standard Operating Environment
- Telecommunication providers
- Device/hardware providers
- Software vendors
- Service providers
Multi party integration and communications can make things quite a bit more complex, so it may be best to err on the side of over-communication. In many organisations in this situation they utilise a service provider to herd all the cats. A thorough stakeholder analysis, asking questions and clearly defining requirements and expectations will make for a smoother and faster project.
To begin the ramp up process, both internal and external teams need to start joint preparation for the project kick off. When preparing to dive into the project, each organization is different, so assume nothing. Variables and needs should be covered-off and agreed upon before moving forward. It doesn’t need to take a great deal of time or cost to cover these (can be done via a meeting or conference call or even sent as a document), and it’s imperative for an efficient and well-managed project.
Project Initiation
A couple of key areas of importance in these complex projects are:
Handover
The nature of the project and availability of resources could dictate a formal hand-over or informal sessions. Ideally by this stage, along with the client’s RFP or RFQ document, there is a formal response from the sales team to the customer. Consider the size and nature of the project and ensure to schedule an appropriate amount of time between sales and delivery to fully understand the expectations.
While not always possible, ideally all three parties (customer, vendor sales, and delivery services) are involved in this hand-over process. If there are issues or misunderstandings between the involved parties, be sure to mitigate appropriately.
Methodology
Customers and vendors may very well differ in their project management methodology. A preferred project methodology may not have been designed with mobile projects in mind. Even the decisions on tailoring and agility will have a big downstream impact. So it’s important that all parties are clear on the methodology for the duration of the project. While this can be a challenge, it ensures everyone is going in the same direction at the same speed and measuring against the same benchmarks.
Deliverables & Templates
Like any good project set expectations, clearly define RACI elements; understand timelines, communications mechanisms, roles and responsibilities. A pointer here is to ensure that your deliverables and associated templates are suitable for a mobile project. For example your Design/Blueprint document will need considerations for Screen Flow, Use Cases, Usability Experience, and Integration.
By their nature a mobile project often involves multiple vendors. One vendor might supply the underlying software technology, another providing User Experience, others responsible for integration, and yet another providing hardware.
A couple of key areas of importance in these complex projects are:
Handover
The nature of the project and availability of resources could dictate a formal hand-over or informal sessions. Ideally by this stage, along with the client’s RFP or RFQ document, there is a formal response from the sales team to the customer. Consider the size and nature of the project and ensure to schedule an appropriate amount of time between sales and delivery to fully understand the expectations.
While not always possible, ideally all three parties (customer, vendor sales, and delivery services) are involved in this hand-over process. If there are issues or misunderstandings between the involved parties, be sure to mitigate appropriately.
Methodology
Customers and vendors may very well differ in their project management methodology. A preferred project methodology may not have been designed with mobile projects in mind. Even the decisions on tailoring and agility will have a big downstream impact. So it’s important that all parties are clear on the methodology for the duration of the project. While this can be a challenge, it ensures everyone is going in the same direction at the same speed and measuring against the same benchmarks.
Deliverables & Templates
Like any good project set expectations, clearly define RACI elements; understand timelines, communications mechanisms, roles and responsibilities. A pointer here is to ensure that your deliverables and associated templates are suitable for a mobile project. For example your Design/Blueprint document will need considerations for Screen Flow, Use Cases, Usability Experience, and Integration.
By their nature a mobile project often involves multiple vendors. One vendor might supply the underlying software technology, another providing User Experience, others responsible for integration, and yet another providing hardware.
Prototyping and/or a Proof of concept
Enterprise mobile projects involve technology that is emerging and changing rapidly. Due to this the stakeholders and decision makers cannot be experts across all the technology and possible options. For this reason, along with the need to visualise User Experience options, enterprise mobile projects will benefit greatly from prototyping. Within an enterprise mobile project it can be difficult to get the best value out of a traditional ‘blueprint everything up front’ approach.
Along with not understanding potential pitfalls it would be easy to miss out on leveraging all the possibilities of the new/emerging technology. Some projects may be able to leverage the build tools for prototyping purposes (or just mock-up examples in a drawing program). Utilising tools that are not fit for purpose can be problematic. The installation, environment, setup, training and, accessibility of build tools may make them difficult to leverage.
With a mobility related project some of the true “right once deploy many” MEAP options will let you pull off a prototyping approach. However not all projects, build tools, and even MEAPs offer great prototyping features. Even when all the stars align can you effectively gather feedback from your audience?
Depending on the size of your project and or the vendors involved it may be worth considering a fit for purpose prototyping product. These products enable rapid prototyping on device (or emulator) along with useful feedback mechanisms. While of course there is an associated cost with using these products it may save you money in the long run.
When to use
The adage about spending more time on design and less on build rings true. With prototyping tools the focus can be on design without needing to spend so much time. These types of tools can be leveraged in various project phases for example:
- Part of RFP/RFQ process to build a mock-up that can be quoted on.
- During the design/blueprint phase to finalise an agreed functional design.
- Throughout the build phase to prototype traditional blueprint/designs.
- Ongoing in support/run phases to formalise change requests
