In the recent past, we had to deep dive into a few projects and execute them at a fairly rapid pace with very tight budgets; one of the most challenging aspects of this is that the requirements do not exist or they are incomplete and there is not enough time to meet all the various stakeholders, understand their needs because business stakeholders are often tied up in running the business. However, as consultants, we are expected to deliver despite the obstacles. In this blog, I just wanted to share a few of the best practices that we learnt at Focal over the past few years and hope that others may find this information helpful.
We pick industries that we are familiar with. Timelines are already a challenge but knowing the industry improves the probability of success so that there is an understanding of processes and a common terminology that everyone aligned with.
In addition to the typical crew such as Project Managers, Tech Leads, Architects etc, if there is an option, our first lesson is to have a Product Manager in place. Product Managers bring in unique perspective of tying in business processes, industry knowledge, user experience and the skills to communicate and present to interact with senior management and leadership. Good Product Managers can identify the epics quickly, raise key issues etc early on the life cycle. In addition, they can augment client’s leadership teams in sharing the vision, training and other ancillary tasks which are common in Product Development.
A Team Charter that highlights all the various stakeholders, their preferred working hours, preferred channels to operate, values, rules of engagement have been very helpful to ensure time and norms are respected all the time. If folks are not adhering to the agreed upon norms, psychological safety should exist to have open discussions around the topics.
Teams should try to minimize email and get used to Wiki. Often times, folks get comfortable with emailing meeting minutes, documents etc which are very difficult to find at a later point and minimize productivity. One important point is which wiki to use? If the client has a wiki culture already, great. If not, it is important to get the buy-in early in the project.
One of the most useful tools that I learnt working on a recent project is maintaining a RAID Log from Day 0. In many projects, I noticed that RAID is created during project kick-off but not kept up-to-date during the lifetime of the project either because it ends up in an Excel that gets tossed around so much that nobody has a clear perspective on where the true version resides or there is no solid Project Manager to take charge of the project. In a recent project, the RAID log was maintained in an app and discussed in every PMO call. That discipline helped everyone understand the risks and act on them in a timely way.
RACI is another tool that I love. As project execution is in full steam, folks lose track of who is responsible for what. Maintaining a RACI on the wiki will ensure that everyone is clear about their specific role in the project. As an example, is it the responsibility of the architect or the Team Lead to come up with the architecture document? Will the architect just review or update the document? Having this clarity upfront has been very helpful.
Many many not have heard of LogFrame is. It is a tool developed and used by Governments. I found this to be extremely helpful to help answer few questions around successful delivery. What does success look like? What are the key metrics that the team should track as success criteria. There could be metrics at various levels. (Goal, Outcomes, Outputs and Activities (Project Plan)) . This requires a different blog and I will write one soon specifically on this topic.
Sometimes, there could be an existing system that is operational that business stakeholders are used to and in a transformation or a “Lift & Shift” Project, when asked for requirements for the operational system, the client may not have access to it or the requirement document/stories may be outdated. In such scenario, we found that in addition to walk-throughs and demos from business and teams undivided attention and curiosity, a few creative methods to identify the requirements are very helpful.
- Training Documents. As an example, Sales and Service usually have their events where the leaders in respective teams create excellent documents to explain teams in the field. Often times, they can be great resources to get an understanding on the processes. Ultimately, it’s about the end-users and whatever functionality exists is to help them.
- SIT & UAT Plans: Before going live, QA Teams must have completely vetted the operational system. The plans and scripts are a treasure hove of information to find useful insights that the teams can understand, discuss and help frame the requirements and ask right questions.
We truly believe that the value of workshops with business will be significantly higher after the above activities are addressed. To properly leverage time from Business, the project team should do their homework, be focused during the workshops (without multi-tasking) and have a preliminary understanding of the flows. In addition, every workshop should be recorded and have transcripts for the complete discussions to be able to understand classify and understand the requirements.
Finally, with help from Leadership, the collective team should dare to build a courageous culture where feedback is shared frequently and acted upon on all fronts.
Hope you find these helpful. COVID has changed ways of working quite significantly and learning to adapt the to new world while maintaining sanity is critical for Employee and Customer Experiences.