Date: May 9, 2024

WHAT YOU NEED TO KNOW: Leading companies will utilize cutting-edge technology for five specific challenges, working with state teams on how GenAI can enhance customer service, improve health care facility inspections for better care, reduce highway congestion, improve safety for vulnerable roadway users, and improve language access.

SACRAMENTO – California is continuing to implement Governor Gavin Newsom’s Executive Order on Generative Artificial Intelligence (GenAI), entering into agreements with five vendors to test, iterate and evaluate GenAI through proofs of concept (POCs). Vendors will utilize GenAI technologies developed by OpenAI, Anthropic, Google, Meta, and others to develop these solutions. The cloud environments used will be Amazon (AWS) Cloud, Google Cloud, Microsoft Azure and ServiceNow (SaaS).

The state will pay each proof-of-concept vendor $1 to test in the “sandbox”, a secure and isolated testing environment. This gives the state and the vendors time to see what works, what doesn’t, and make necessary adjustments during a 6-month window.

“We are now at a point where we can begin understanding if GenAI can provide us with viable solutions while supporting the state workforce,” said Amy Tong, Secretary of the California Government Operations Agency. “Our job is to learn by testing, and we’ll do this by having a human in the loop at every step so that we’re building confidence in this new technology.”

Download the complete GovOps press release for additional information.

SymSoft is thrilled to have been selected for the GenAI POC for the California Department of Tax and Fee Administration (CDTFA). As quoted in the press release:

“SymSoft is enthusiastic about the potential of Generative AI to elevate Customer Service and Customer Engagement,” said Savita Farooqui, Director of Research, SymSoft Solutions. Our approach not only enhances operational efficiency but also enriches the customer experience. By implementing robust AI governance and effective safeguards, we are dedicated to delivering AI solutions that genuinely benefit our customers.”

Kevin shares his perspective—and we further elaborate—on:

1. Forming partnerships up, down, and across the organization.
2. How to select the right vendor partner for the intranet project?
3. How to deliver a project in 90 days by accelerating the project timeline?
4. 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:

1. 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? 
2. 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?
3. 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:

1. 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.

2. 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.

3. 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.

4. 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. 

5. 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.

6. 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:

1. Commit to the minimum projects requirements.
2. Define project goals and success criteria.
3. Secure executive sponsorship.
4. 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:

1. 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.

2. 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.

3. 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.

4. 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.

Some organizations have not adopted intranet platforms, instead opting to rely on a variety of other solutions, such as email and third-party messenger systems. Others have implemented intranets which, after years or decades of growth and changes in organizational scope and scale, no longer meet their present-day goals and vision.

Whether you have an existing intranet or not, there are common problems that can indicate that a modern intranet system is necessary for your continued success.

Organizations sometimes reach a halt where the necessary scope of a new intranet system is daunting, but the ability to grow and improve their level of service requires attacking the problem.

In early 2019, we were approached by the California Department of Water Resources. The scope of the DWR is immense. They are responsible for supplying water to 27 million Californians and 750,000 acres of agricultural land, and also provide oversight for more than a dozen dams in the state of California. These responsibilities require a large, diverse workforce: the DWR is composed of approximately 3,500 employees across 14 offices in various urban and rural locations.

As you can imagine, any and every hindrance to communication was keenly felt. They knew their needs had outstripped their existing internal communication infrastructure. But it takes a significant, committed effort to shift focus from short-term, day-to-day priorities, and taking a step back and seeing the big picture.

To their credit, DWR recognized they had hit a point where they couldn’t hide from the challenge any longer, and had to get all relevant stakeholders involved: execs, operations, IT, communications, HR and legal, and of course, their base level employees.

An inadequate intranet often results in the loss or misplacement of institutional information, failures in communication between executives and employees, and ongoing difficulties for the rank-and-file.

The difficulties that arise from aging, insufficient intranet are often felt both at the organizational level, and at the personal level.

Problems that arise at the macro scale can include:

• Loss of documentation. Documents—both archival and current—can become difficult to find, as employees come and go and filing systems shift and change over time. It can become necessary to conduct weeks- or months-long content audits to identify what documents exist, and where.
• Disjointed communication. As with document archives, an inadequate intranet system results in the fragmentation of every aspect of communication. Knowledge is lost, performance metrics are opaque, and efficiency is compromised. The result is an incoherent execution of an organization’s vision, mission, and values.
• Social isolation. As a result of poor communication, workers often feel isolated, cut off from others by the four walls around them. They have no way of seeing the larger picture, and no way to appreciate the positive impact of their work. Work often comes to feel repetitive and unfulfilling at all levels.
• Lack of community and mission. Public social media platforms are appealing for a reason—they give a sense of community and connection. Failure to provide for the social needs of the workforce results in an organization that has no central identity, with mission statements that carry little or no real-world weight. Organizational plans, milestones, and updates are not shared, never making it out the door of the boardroom.

Shortcomings in intranet sophistication are also evident to the rank-and-file. Common employee-level issues include:

• Intranet as info dump. A lackluster intranet often becomes nothing more than a bucket for informational storage. In these instances, file search and navigation features are inadequate. This means that documents, manuals, and guidelines are difficult or impossible to find, and multiple, conflicting versions are generated over time.
• Distribution outside the intranet. In these situations, the sharing of information often occurs outside of the intranet, with employees instead relying on email, and third-party messengers like Teams and Slack. Consequently, not everyone has the same information, or even the ability to access the same information.
• Improper data storage. Because of distribution occurring outside the intranet, files are often archived as email attachments or in user drives, rather than in common storage.
• Success not communicated. With an intranet not being an effective means of communication, personnel successes are never communicated.

But the most obvious symptom of an inadequate intranet is that it delivers an experience that is subpar to Internet services and third-party communication tools, so that it becomes the option of last resort.

But these are problems that can be resolved by making a comprehensive, top-to-bottom commitment to developing an intranet that betters your entire organization.

To return to the challenge facing our client, DWR, they recognized that their existing intranet did not serve the needs of their employees. A platform was needed that was flexible enough to accommodate the unique needs of each employee, as well as a unified connection and understanding of key needs and goals.

In the summer of 2019, we brought together over a hundred and twenty employees to participate in focus groups for the intranet redesign. These participants were specifically selected to better understand the diverse needs within the workforce, based on their skills, geography, and position within the network. Employees were asked to provide feedback on knowledge search information operation and networking. Our team listened and learned from DWR’s employees. And then, we prioritized those needs moving forward.

It was a significant challenge. But we succeeded because we led off by asking a handful of critical questions:

• If you could wave a magic wand, what are the three things you would fix immediately?
• What are you doing right now to address organizational challenges? What has worked, and what hasn’t?
• What are the long-term goals of the organization?
• How would the success of the project be measured?

In the future, we will address how we develop a successful intranet system that meets the needs of an organization’s mission, as well as its rank-and-file staff. But every successful intranet project addresses three key needs:

• Accountability. At the outset, personnel are identified as being responsible for the successful execution of the project, so that the organization’s mission, values, and vision are sustained.
• Curation. Any successful intranet requires ongoing information curation, to ensure consistency in organization. There must be dedicated resources in place which will edit content, optimize, review, archive outdated content, track intranet performance, talk to employees, and conduct regular (often light weight) UX studies.
• Adoption. An intranet is not a project that, once it is completed, it is placed on a shelf. It is an operational asset. Plans must be put in place for how the organization will transition from the old intranet system, to the newly developed one. All stakeholders must commit to making this transition. Otherwise, the organization will be in limbo between the legacy system, and the new one.

In future posts, we will address other key topics in the development and launch of successful intranet systems. In the meantime, enjoy the video presentation we delivered at Sitecore Symposium and contact us with specific inquiries about your intranet project.