Planning

Scope Definition: For the Scope definition, this would require investigating and detailing the project’s objectives, deliverables, and boundaries.

• User Scope - how could we know what scope needed to be defined outside of internal stakeholders? This needed to be determined before product and design scope definition could be set. A timeframe for product investigation was set and user surveys were scheduled. Through these surveys, feature needs were discovered that had not been initially listed by internal stakeholders. I logged and reported findings so that awareness was set for help with MVP feature sign off.

• Technical Scope - developers had a great deal of tooling that would need to be implemented that may not be understood by the leadership team due to not all leadership members having engineering knowledge. These items were logged and brought to the attention of leadership so that there was a larger understanding of technical needs and potential timelines.

• Marketing Scope - User adoption and tracking was needed not only for metrics around product use, but also who were our users and how could we advocate the product to those who needed our services but were not aware. Scope was identified for marketing needs and what risks may occur if these were not implemented.

• Sales Scope - scope was identified by sales team members who had specific needs for their clients that needed to be implemented into the MVP as a must have. Any scope of work paid for in the MVP by clients was added to the scope for the MVP. Any items outside of must have were logged to be backlogged and reviewed at a later date. I captured all items requested in a separate area so that requests were not lost but also not mixed in with MVP scope requirements. These items could be reviewed and vetted with leadership for future work if approved or needed.

• Leadership Scope - items found from user surveys, product team suggested features, marketing scope, and sales scope was compiled into lists for voting by the leadership. Through this process, MVP features were selected. I created and outlined the list of needed features from the scope so as to create epics with feature lists, as well as to house future user stories.

Resource Planning: Identifying the resources (people, equipment, budget) required.

• Team Resources - identified as a need and hired:

  • UX Lead

  • UI Designer

  • Front End Developer with Fullstack capabilities

• Third Party Vendor Resources

  • AR/Mapping 3rd party vendor

  • Localization vendor for languages

  • Legal Services for privacy policies, terms of service, and feature development verbiage and use where risks are involved

• Application Resources - request to move all teams onto one application for tracking and organizing the project

  • Azure DevOps: ADO was identified as the preferred application to tracking cross team items and progress. I was requested to move all users from Jira and Confluence to ADO as well as train any members not familiar with ADO so that they understood the application and could easily work with their tasks and objectives. I set up the projects within Azure DevOps, loaded all applicable team members with permissions based on role to the application as well as trained users how to use the application.

• Equipment Resources - Equipment resources were already determined at this time. However through further scope definition and expectations as the project progressed, I vied for more testing devices as we found through user tracking and testing which devices may not have been accounted for in their original estimation.

Timeline Creation: Timeline for the project schedule had been predetermined before my hire. A roadmap existed with multiple months given to product and design and only six weeks for development. I immediately identified that this was a very large risk and that six weeks would not be enough time to develop this product. Without the authority to change this timeframe, I identified this as a very large risk and escalated the concern through proper company procedures to the leadership team as well as heads of departments. My past experience with rebuilding from the ground up is that a small MVP would take months, not weeks to implement.

I created updated roadmaps and milestones based on scope and given timeframes.

Risk Management Planning: I identified all current potential risks for the project and maintained with updates the risks throughout the project. Any mitigation needed was outlined and suggested to leadership for decisions on changes needed, approvals, and implementation.

Communication Planning: I establishing protocols for information dissemination among stakeholders and implemented strategies to inform stakeholders and teams of progress, blocks, and changes.

Budgeting: Budget was pre-established before my hire.

Execution

Issues - there were several issues around beginning execution. The Product Team (UX UI/Design) was not currently ahead of the development team. They were behind due to current flagship requests and could not start on the design work for the product redesign. This included conflicts for time needed for user surveys and working with the leadership team to establish the MVP. I identified and communicated these issues as risks to the project and that intervention was needed from leadership on work approval so that the Product Team’s time was protected or the project would be at risk for not meeting deadlines.

Goals - My goal was to reset expectations of what work the Product Team would be working on as well as to get the Product Team ahead of the Engineering Team. This way work was ready and clearly communicated that the work was ready for development so that backlog selection for sprint work could be easily determined and selected knowing that the stories had complete design and story information for developers and QA.

It took some time and effort to redirect requests to the Product and Engineering Teams in order for focus on the product revamp to work as all other teams were used to being able to go directly to product or team members with requests and those requests may have been squeezed in or worked on without approval based on previous team member habits before adding me to the company. I worked to implement awareness and processes so that the requests for work were funneled through me and work without authorization stopped. This allowed the Product Team to conduct user surveys, create findings for the leadership team to vote on features, and set MVP scope.

I worked with the Product Team to establish user stories within epics and features so that a prioritized list was available to the development team and the user stories and design work was then available for developers ahead of time vs. developers waiting for design requirements during sprints. The Product Team is now successfully not only ahead on work for the product, but has been able to establish features, stories, and design work for multiple projects as well as the future features for the current product beyond MVP.

Task Assignment: I used two week sprints to allocating tasks to team members for project work. Roadmap and milestone goals were used through planning as I used the Agile ceremonies to create sprint goals and allocate work to team members. Developers were able to implement tooling for the project as well as take on design stories to create the MVP.

Resource load and assignments were considered during sprint planning in order to not only give stories to those developers who had strengths and knowledge to take on more complicated tasks, but to also implement pairing tasks for junior developers who would benefit from learning on work together with senior developers. This helped not only foster team work relationships, but to also expand the capabilities of the current engineering team. This helped move the project along at a faster pace with less bugs as there was a tight deadline for the work.

Team Management: For leading and managing the Project and Engineering teams, I implemented Agile ceremonies for daily standups, pre-backlog refinement, backlog refinement, sprint planning, sprint review and retrospectives to ensure cross-team collaboration and understanding.

I also coordinated when sales demo events with the development team so as to not clog product server speeds or push features that were not ready for clients during those demos, as well as coordinated with the mapping teams for when new client maps were ready to be used with the new product. The product depends on maps being available as well as in the correct new updated format. Maps must also have the ability to be translated so that users localized in other countries where English is not the first language, those users can easily read maps contained with the product in the localized language they desire.

Quality Assurance: Monitoring and controlling the quality of work to ensure it meets the project standards was done through sprint work as well as regression testing throughout the development of the project. Reworking expectations for clarity on acceptance criteria was a focus so that we were developing features that were understood by both developers and the designers approved the progress and implementation. Continual communication and improvement on our processes helped to align the teams for clearly created tested features.

Mixpanel implementation as well as in person user testing on location helped to determine blind spots for when users were not able to adopt the application. Examples, this may be due to either learning that users had different devices than originally projected, or by watching and working with users to understand where designed and implemented features may not have been clear. Through frequent user testing, we were able to implement updates for device types and feature sets in order to help alleviate expectation issues.

Stakeholder Communication: In order to keep stakeholders informed about progress and changes, and to coordinate with the broader company teams, and leadership, I held weekly or bi-weekly meetings (depending on needs and teams) to communicate progress, risks, issues, and to help coordinate any moving parts that needed to happen.

All risks were clearly communicated for scope, progress, and any issues during that time. Leadership decisions based on communication of risks and stakeholder needs I implemented and passed down to the appropriate teams or team members.

Monitoring and Controlling

Performance Tracking: I Monitored all progress against the project plan and communicated when items were or may be off track, what the impacts might be, and any mitigation needed.

Scope Management: Project scope was communicated to leadership and any changes needed were managed.

Risk Management: I monitored and identified risks for both the Product and Engineering Team as well as implemented any mitigation plans as necessary.

Quality Control: I ensuring that project deliverables meet the established standards based on continuous testing as well as improvements on requirements and acceptance criteria so that stories and feature sets were clear to all team members.

Budget Management: I created budget projections based on features the sales team would like to implement. This helped the team decided whether to pursue or drop features needed. This helped to show scope, time, and funds needed so that the leadership could determine what items would be viable based on costs and benefits.