Project Success Story: Implementing a Customer-Centric Strategic Project the Agile Way
This story from Lance Hamel, is about a complex Customer-centric strategic project to improve customer experience in the Retail Industry that took 7 months to complete. The complexity was due to having to implement an unknown cloud-based solution using an agile approach in a traditional waterfall environment, with an unknown vendor. The systems integrator promised technical skills some of which they didn’t have, and subsequently had to be outsourced. That delay caused increased pressure towards the end of the project.
Going Agile
After less successful prior attempts, the team was mobilised quickly and was able to deliver a minimum viable product (MVP) after 6 months. This was an early win for the business and it took about one third of the time it normally takes to implement a new solution.
The Business had an active and involved project sponsor who was also the product owner. Through-out the life-cycle of project, following an Agile approach, the project team was aligned on a daily basis. The Sponsor had a briefing 2-3 times a week, when she did regular prioritisation with her team; therefore there was a close alignment between business and the project team.
The vendor was leading the agile process. They had a very transparent way of working between IT and Business,. The right stakeholders were involved with sprint planning, backlog grooming, reviews and briefings. They also attended sprint reviews/retrospectives in a continuous improvement process.
New way to manage projects
There was a complete shift in the way they managed the project. Instead of …..
Read more ….. for many lessons learned and key take-aways for future projects.
Project Success Story: Implementing a Customer-Centric Strategic Project the Agile Way
This story from Lance Hamel, is about a complex Customer-centric strategic project to improve customer experience in the Retail Industry that took 7 months to complete. The complexity was due to having to implement an unknown cloud-based solution using an agile approach in a traditional waterfall environment, with an unknown vendor. The systems integrator promised technical skills some of which they didn’t have, and subsequently had to be outsourced. That delay caused increased pressure towards the end of the project.
Going Agile
After less successful prior attempts, the team was mobilised quickly and was able to deliver a minimum viable product (MVP) after 6 months. This was an early win for the business and it took about one third of the time it normally takes to implement a new solution.
The Business had an active and involved project sponsor who was also the product owner. Through-out the life-cycle of project, following an Agile approach, the project team was aligned on a daily basis. The Sponsor had a briefing 2-3 times a week, when she did regular prioritisation with her team; therefore there was a close alignment between business and the project team.
The vendor was leading the agile process. They had a very transparent way of working between IT and Business,. The right stakeholders were involved with sprint planning, backlog grooming, reviews and briefings. They also attended sprint reviews/retrospectives in a continuous improvement process.
New way to manage projects
There was a complete shift in the way they managed the project. Instead of email, phone and meetings, the project was managed via social media. Business requirements were captured as a User Story, with test scenarios. The team worked online all the time which facilitated some remote (offshore and intercity) collaboration.
Co-location
Another important contributor to the success of this project was the co-location of the team – all key players, had the use of a dedicated room. There were at times, up to 25 people working together and collaborating on project work.
Developers were involved through the design, testers were involved early on, and business team members were part of huddle groups. The approach followed was to go through iterations, build it fast. It was about speed (early value).
Choice of tools
The tool in use was SF Tracker with Chatter, and the team moved away from MS Project, PowerPoint and Word to an online collaboration tool including social media capabilities like instant messaging. Members would follow threads, could see questions, blockers. They had the tool on mobile devices and laptops. It was a very collaborative toolset.
The best thing was the move away from using emails or Word documents being sent around. Documents would be attached to User Stories where required. Generally the way of working was to collaborate between the business and team to ensure the correct solution to requirements were delivered as soon as possible.
Good Budgeting process
By having a good budget process of using Capex and Opex components, when operationalised, the project had access to the Opex budget to bring Administration and Support staff on board, while still automating the solution funded by Capex.
The team had to manage scope additions; within the same timeline and budget. To enable this, the business had to de-prioritise certain work and added more time; but mostly stayed within budget.
Challenges
The project had a fixed timeline and fixed budget, with the only flexible constraint being scope. Since the Business clarified additional requirements and the vendors had a skills shortage, stakeholder expectations had to be managed. More work couldn’t be expected only in 4 sprints of 2-3 weeks each. The project management had to ask additional funding for more time and added one more sprint.
The project team couldn’t deliver on all the requirements but the close collaboration with the project sponsor ensured that there were no surprises.
The Vendor helped deliver a production ready solution, but it was not live in production yet. The deployment cycle, stabilisation, automation and processes took another 3-6 months before there was an automated solution running. The Vendor left after the solution was put in production but before it was fully stabilised.
The team had to juggle with remaining resources between supporting and building the stabilisation components and finishing what wasn’t built right to have a stable environment.
Lessons Learned
There is a requirement to add closure sprints to allow enough time to operationalise at end of the project.
The project team evolved to better partners who provided better resources, and who were more skilled than the original service provider. It was only towards the end of the project that the project team knew what they want from a partner.
As a result of the speed within which the solution was implemented, it forced the PM and team to learn much in a short space of time.
Online collaboration, dedicated resources and co-location are massive benefits for Agile teams.
Keep a tight and ongoing relationships with the Business to stay aligned with what they want. It’s a good practice to have an allocation of both an IT and Business project manager.
Key take-aways
Self-learning and continuous improvement is important for the PM and each team member.
To collaborate better, mobilising faster, staying aligned with the business and their needs.
It’s about the collaboration and relationships, more than what tools you use.
Stick to the agreed principles and the process.
Be transparent, issues are visible immediately and have to be addressed, resolved very quickly. Learn from mistakes and keep improving how things are done.
About Lance Hamel: Lance has been involved with projects for the past 22 yrs, starting with ERP implementations. He evolved from being a Technical Lead to being a Technical PM. For the last 7 years his focus was on project management, and programme management. He learned the Agile approach by immersion and is now playing a lead role for Agile projects.
He may be contacted on: lance.hamel@digitalworkforce.co.za
Related
Leave a Reply
Manage Cookie Consent
We use cookies to optimize our website and our service.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.