This article is the second part of our Department of Water Resources’ Intranet case study that Bianca Sievers, Kevin See, and Bhavik Patel presented at Sitecore Symposium 2020. In case you missed it, read the previous part about Intranet business opportunities and how to identify them.
Kevin shares his perspective—and we further elaborate—on:
- Forming partnerships up, down, and across the organization.
- How to select the right vendor partner for the intranet project?
- How to deliver a project in 90 days by accelerating the project timeline?
- How can rapid prototyping be incorporated into a time-constrained project?
Watch the video starting at about 3 minutes in, or skip to specific parts using the links above.
DWR’s intranet project was successful in large part because of the stakeholders’ attention and the team’s dedication. To deliver the project in such a short timeframe (90 days), we needed to form strong partnerships:
Kevin See: Now, here comes the fun part. How did we do it? We had to form partnerships — the partnership with the business, the partnership with technology, and of course, our vendor partnership. The first really big piece is — our director was in full support of this initiative, but we also had executive sponsorship from our deputy director of business operations, which runs the horizontal business. So everything from HR to IT is run under business operations.
The next part is the partnership between the director’s office, where Bianca is at, and the technology office [Kevin’s office]. Bianca represents the policy, the content, and the features people want. I represent the technology in terms of how we did it.
The last very important piece is that partner engagement. We had to find a partner that met the speed we wanted to go with, that also shared the same values, vision, and goals that we wanted to share. And have the flexibility to dynamically shift where we needed to to get the job done. And that was really [the case] with our SymSoft partner and working with Bhavik.
[The transcript was edited for clarity and brevity from the original audio recording. References to the slides were removed from the transcript.]
Forming partnerships up, down, and across the organization is crucial for the success of an intranet project.
In a typical project, vertical communication between supervisors and their reports is a natural extension of a regular reporting routine. Many times though, that same routine and reporting frameworks can steal attention from the project at hand, because other things may take priority or urgency, and meetings may be repurposed for other pressing topics. Also, while it makes perfect sense to include stakeholders from across different divisions and offices, oftentimes their attention is elsewhere, and their calendars are difficult to coordinate.
In short, partnerships require dedication, structure, and excitement, which is in many cases much easier to accomplish if the team is nimble and focused and the communication is direct and candid, instead of managed and indirect.
Not everyone has the opportunity to form small teams as we had at the DWR’s project. This is why in large organizations, we often suggest inviting divisional representatives with decision-making power delegated by the division’s head. And especially if the division executives are stretched too thin by directly participating in the project. A useful model for defining stakeholder roles and responsibilities is the RACI matrix, which describes who is Responsible, Accountable, Consulted, and Informed.
To secure resources and bandwidth across divisions get executive support with a clear vision for the project’s success. Equip your leadership with talking points and clear engagement requirements, so that they can relay the message with better clarity about the timelines, efforts, expectations, and specific action items. It’s much easier for divisions to commit resources when expectations are clear.
How to select the right vendor partner for the intranet project?
To identify whether the vendor partnership will be successful, it’s useful to ask a few questions:
- What type(s) of vendor contributors are you going to collaborate with during the course of the project? Will you work with the experts directly, or will someone be a liaison between you and the expert? Are you looking for a vendor that can participate in strategic decisions, or are you looking at the production partner only?
- What is the team’s availability for the length of the project? Who is engaged at different stages of the project? What will the handover from discovery, to design, to development, to deployment look like? Is there any quality control to ensure a smooth transition between different stages of the project?
- What are some other functions inside the client organization that might contribute to the project? What will be their availability? Will we get reviews and approvals in a timely manner? How will the project team present work in progress to internal stakeholders and seek feedback?
Asking these questions from the perspective of the project goal will help you realistically allocate internal resources, budget for external help, and set timeline expectations.
Now that we identified partnership considerations, let’s explore some practical tips and tricks that can help us accelerate project delivery.
How to deliver a project in 90 days by accelerating the project timeline?
Let’s start with Kevin’s insights from the intranet project:
Kevin See: The “how” part is the agile delivery model. We had 90 days to get it done. Why 90 days? We had to get it done by Christmas time. That was our goal. Our time and our resources were tightly controlled. Our scope was to build an awesome and engaging intranet that employees love. It is very broad in scope in terms of what it’s going to be delivered.
Our time, as I mentioned, 90 days, got to get it done by Christmas time. Our resources? Well, that was our team. We had the resources that we had, and that was it. So we had to do all that within this very short and tight scope and build the intranet that people would use.
Decision- and policy-makers were a part of the product team. It wasn’t where we had a decision- and policy-makers that met once a month to talk about where the challenges are. The typical process in terms of how it goes is a steering committee. [But] they were actually a part of the team on a day-to-day basis. Bianca and I met literally every day or every other day. Between Bianca, Bhavik, and myself, we saw each other more than we saw our families within this 90-day timeframe. We shared a single vision, the vision of building the intranet that employees love, the vision of building the intranet within 90 days. And to get it done.
How did we apply agile delivery to the DWR’s intranet project?
To help us accelerate the project timeline, we used the agile delivery model and rapid prototyping (more about rapid prototyping below). We were able to utilize agile delivery because we met a couple of important essential ingredients:
- We worked as a small, fast team. While it is possible to apply agile delivery to a much bigger team of teams, it would require some preparation time to organize decentralized communication between smaller teams that follow the agile approach. We didn’t have the luxury to step back, so individual team members instead prioritized this project and focused on fully understanding the ins and outs in order to make informed decisions. By keeping the team small, we completely removed any overhead.
- We communicated daily. Granted, daily communication wouldn’t be possible with a much larger team spread across multiple projects. The cost of task and project switching would be too high, and it would require additional effort to maintain the common vision and priorities.
- We provided feedback instantly. When the team is focused on the project with little to no distractions, feedback and decisions are made on-the-fly and based on shared understanding and common knowledge of the project.
- We made quick adjustments and shortened release cycles. Because the team was very intimate with the technical platform (Sitecore), it was possible for us to update and compile features and to try different options. This wouldn’t be possible without both content and platform owners’ expertise in content publishing on the Web.
- We trusted one another. To develop trust, it is important to have a vision of the outcome that is attainable as well as assemble a team that shares that vision. A clear vision also helps with prioritizing features.
- We prioritized features based on the project goals. As we were developing and implementing features, we developed a good sense of how much each addition or change would impact timelines and efforts. Instead of only focusing on development time, we also considered organizational policies and content governance. A good method for feature prioritization is the MoSCoW analysis that identifies Must-have, Should-have, Could-have, and Will-not-have features.
If your organization hasn’t already adopted an agile methodology, we suggest trying it with a small team that can operate within the framework described above. It is also useful to start implementing agile in your organization by following the agile manifesto:
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
How to prepare for a tight deadline project?
Even if you don’t follow agile methodology, or are not sure if you’d end up applying it, any project can move quickly and meet deadlines with some basic preparation:
- Commit to the minimum projects requirements.
- Define project goals and success criteria.
- Secure executive sponsorship.
- Book important meetings far in advance.
How to keep the project moving?
There are also a number of simple practices teams can implement and stick to in order to keep making good progress and avoid pitfalls:
- Appoint a project manager who will attend all meetings, track decisions, and serve as an information hub. Best results are accomplished when they work closely with the vendor’s project manager.
- Show something tangible early. It’s much more cost-effective to course-correct a proof of concept or a prototype than a fully developed project. Depending on the fidelity level, and stakeholder experience, it’s a good idea to present progress in a broader context of project requirements.
- Keep key decision-makers in the loop by presenting small changes often. This will make it easy for them to recall the previous decisions and ask questions early, rather than approving a major milestone without enough context.
- Contain the scope by always going back to the minimum project requirements. Any additional ideas and opportunities should be moved to the backlog and revised after the must-have features are designed, implemented, and tested.
How can rapid prototyping be incorporated into a time-constrained project?
DWR’s team is a huge fan of rapid prototyping, especially since they were deeply invested in the project and excited about the possibilities.
The line between rapid prototyping and agile methodology is sometimes blurry. Rapid prototyping focuses on the software design from the user and business stakeholder perspective, while agile methodology applies to software development. The confusion stems from the fact that both are iterative methodologies with short release cycles, and both can be performed in the software environment. Still, it’s important to remember that prototypes are not production-ready.
For example, before committing to a full-blown web form that connects to various systems and databases, you might embed a Google Form into a page to validate the user flow. Or, before committing to a custom developed data-dashboard, you might embed a Tableau prototype as an iframe. Yet another example is prototyping a widget without actually connecting it to the database. None of these examples would be shipped to production, but would give everyone a good idea of whether the feature makes sense to develop further or not.
Compared to the waterfall approach, which includes detailed planning and rigid requirements outside of the development environment, rapid prototyping enables quick validation of scaled features and provides a short feedback loop. In short, rapid prototyping boosts decision-making processes, dramatically reducing refactoring in the actual development phase.
Kevin See: We’ve done a lot of things in terms of rapid prototyping, meaning: what we saw in the morning could be dramatically different by the evening time. It can be 180 degrees. “You know what? That feature worked. [Or] it didn’t work.” What was the benefit behind that? We might have lost a couple of hours. In a typical development timeframe, a feature might take weeks or months to get done, and you lost all that time. But we worked with a partner, with a business that really was aligned with what we were trying to do, and that is to get the job done, and course-correct and shift, as fast as we want to shift and course-correct.
I think this was pivotal in terms of getting the platform that can do that, finding a partner that’s willing to do that with you, and a business that is truly engaged and is a part of that process. “Yep, that didn’t work. Let’s move on. Yep, that worked. Let’s move on.” And I think this is key in how we got this thing done within this very tight and short timeframe of building the Department of Water Resources’ intranet.
As previously mentioned, rapid prototyping goes hand in hand with the agile methodology, because it streamlines quick adjustments and shortened release cycles. However, it is the most suitable for experienced teams who can make such quick changes, validate options with stakeholders, and make informed decisions. This can also be a disadvantage, since rapid prototyping requires the most knowledgeable and experienced personnel.
Lastly, rapid prototyping is also effective in MVP (minimum viable product) development, where the PoC (proof of concept) is more important than a specific implementation approach. When the timeline is short, rapid prototyping results in a tangible output very early. Once approved, the MVP can be moved into the development phase.
Conclusion
While large-scale capital projects can be delivered in a very short timeframe, they require an experienced team, executive support, and dedicated stakeholders. By applying methodologies and frameworks, such as RACI stakeholder roles, MoSCoW prioritization, agile project management, and rapid prototyping, even the most challenging projects can be delivered on time and budget.
Have a massive project that needs to be delivered fast? Contact us and let’s start the conversation.