CIOs and project managers are often overburdened with the management of multiple IT projects with several interdependencies. While application outsourcing is often seen as a viable option towards the reduction of this application development backlog, completing such projects within planned budgets and timeframes is never easy.
In the previous blog, we discussed how you can choose an application development company with a long-term business focus. This is crucial for optimum management of projects as dealing with a single vendor can help you achieve higher process efficiency and better coordination on multiple interlinked projects.
Aligning business objectives and project goals
It is a widely known fact that the majority of application outsourcing projects fail due to poor requirements gathering, analysis, and planning. For example, it is seen that retailers usually invest in mobile app development to increase online sales. However, the business objective of higher online sales can also be achieved with a mobile website or a progressive web app. Hence, it is important that the vendor and the client have a common understanding of business goals before they finalize a particular project requirement.
This entails higher collaboration between the client and the vendor in the early stages of solution definition. While business objectives are likely to remain more or less constant, the project requirements might change over the course of a project. For this change management, organizations used to create and rely on a requirement traceability matrix (RTM document). However, these days Agile based software project management tools provide better transparency with version-control and change-tracking facilities, effectively removing the need for RTM documentation.
Defining the Scope
While business owners usually want to restrict their roles to validating and accepting the final builds, they must go beyond their comfort level in defining the scope of a project. In the traditional method of software project management, the software vendor was expected to create an outline of the key deliverables at every stage of the project. This used to translate into creation of a schedule of measurable deliverables, as described below:
However, this method of requirements and scope documentation is very tedious and time-consuming as all requirements have to be envisioned in advance with considerable detail. While this method, in theory, left little to chance, the downside was that specification document used to eat up a lot of valuable time. Further, the requirements would change during the project with new discoveries often rendering the Scope document obsolete.
In an Agile project, Scope is defined by high-level requirements, also known as User Stories. While details on these requirements are critical, they are produced just-in-time. This means that detailed documentation of user stories is done on Sprint-by-Sprint basis, where there is a possibility to fail early, make new discoveries and make relevant changes in the User Story backlog for upcoming Sprints. This ensures that there is no wastage in specifying things that might not be needed. Further, this approach provides enough room for change – which otherwise becomes a point of debate in waterfall based methodologies. Change management is easier in Agile:
Things You Must Know about Change Management in an Agile environment
- The goal of Agile is to enable change management, not prevent it.
- Change management is inevitable in Agile.
- There should be no change management during an iteration.
- Change management does not mean no prioritization.
- Change management does not change highest value story scheduling.
- Agile does not eliminate change management challenges but provides a disciplined, streamlined way to manage them.
If you have subjective expectations on quality, then you are in for a surprise. As soon as you develop an understanding of the key deliverables for initial sprint, you should start working with the application development company on defining the parameters for quality assurance evaluation. In Agile this is accepted as a collaborative ongoing process where User Stories are developed just-in-time along with their Acceptance Criteria (AC). AC ensure that all the parameters of a User Story are met as per every stakeholders’ agreement. Only when the AC are “Accepted” the user story is marked as “Done”.
Ideally, AC should have only two values – either acceptable or not acceptable. There is no place for partially acceptable. To ensure this, AC have to be carefully defined with some measurable or tangible parameter. Sometimes, it might also be possible to link payments with AC. That’s why project management experts usually advise including AC in contractual agreements on external projects. However, this might involve lengthy documentation with AC being defined within the requirement and project scope statement. Nonetheless, defining AC in advance can save a lot of hours and money usually spent in change management related disputes.
In the past, schedule management used to depend on a very lengthy document based procedure. It involved defining the critical-path, which was a complex process, often based on inaccurate assumptions/estimates.
Unlike the past, when the focus was to schedule every single task, an Agile approach relies on visually communicating the high-level definitions of the project deliverables. Agile provides facilities to schedule lower level features and tasks in a flexible way where builds are delivered in short sprints.
Planning of these short sprints is easier and more accurate than any other scheduling method used in the past. Teams using Scrum often size their backlogs with Fibonacci effort-points and prioritize feature deliveries with MoSCoW prioritization. As discussed earlier, the product owner will need a clear understanding of business objectives for this prioritization.Also, an Agile team can provide you a fairly accurate time-estimate which is based on the empirical data on effort-points, velocity, and approximate hours taken to complete one story point. Further, you can get the visibility into an ongoing project schedule during a team’s iteration planning meet and daily standups.
Also, an Agile team can provide you a fairly accurate time-estimate which is based on the empirical data on effort-points, velocity, and approximate hours taken to complete one story point. Further, you can get the visibility into an ongoing project schedule during a team’s iteration planning meet and daily standups.
In addition to the quality, scope, and time, the cost of your offshore software development project will also depend heavily on the resource allocation. If you have a higher budget, you can easily reduce the time and improve quality by hiring a large team of experienced developers. A project manager can also put multiple teams in parallel to work on a prioritized backlog. Here’s the typical Agile team structure in an offshore software development project:
The term elastic team refers to a team in which additional resources are scaled up and down as needed. For all budget, timeline, and resource allocation related projections, you will need a Project Management Solution. You can checkout AgileFirst, which is a simple and free software project management software that allows you to manage your project in an Agile manner.
Credencys is currently using an MVP version of this software to manage its Blueprint workshops with its clients. Blueprint is a collaborative workshop from Credencys for Small & Medium Enterprises. With the help of this workshop you can convert your mobile application’s idea into a working prototype/POC/MVP. The Blueprint workshop will help you create a roadmap for the mobile app development starting from building a proof of concept to creating clickable prototypes and MVPs.
Credencys Solutions Inc is a leading mobile application development company and solutions provider. You can contact us for mobile strategy consulting and developing mobile apps for multiple platforms. Subscribe to our blogs for getting similar articles on software project management, strategy, leadership and more.