By Terry Daffin, PMP and Denise Larcade, Prosci

KAI Partners has recently been using design thinking to help create new products and improve existing processes to support the work we do for our clients. Even before the stay at home orders, one of our design thinking teams held a design sprint that was done almost completely remotely—and resulted in a product ready for implementation!

Here are some of our experiences and what we learned through our remote design thinking experience.

Remote Design Thinking Challenges

As with using any kind of new approach or methodology, there were some challenges and we certainly went through the 5 stages of group development: Forming, Storming, Norming, Performing, and Adjourning.

Working remotely added another level of complexity with the addition of anonymity or facelessness. With a lot of strong personalities on our team, it was easy for some folks to disengage from the group.

So, how did we get past this?

To get through the storming phase, we had to work together to develop trust and respect.

True trust and respect empowered the team and were ultimately what led us to the norming and performing stages.

Because we met virtually (over Zoom) once a week, we had to become more vocal than usual. It was not uncommon for members of the group to speak up in order to keep others on task so that we did not go down a path not in scope or bring up topics that should be added to the backlog for future discussion.

Remote Design Thinking Successes

Despite our initial challenges, we did make it to the norming and performing stages! How?

We didn’t wait for people to join in order to begin—we jumped right in and started working.

What made this easier were our tools—we used MS Teams to share files, document meeting notes, have team conversations, and even to build our prototype. There was rarely an occasion where people felt out of the loop, because all the notes, resources, and information were right there in Teams.

Working remotely also allowed us to reach more people, cross more boundaries, and include more perspectives, as opposed to in-person coordination.

People are busy (and that’s a different problem for another blog post!) but working remotely gave more people the opportunity to participate and contribute.

Self-Organizing Team Tips

Part of our remote design thinking method was to truly self-organize within our team. Here’s what worked for us:

Set expectations and make team agreements from the start.

Because there was not one person designated as our “Lead,” we created a list in Teams with the Facilitator and Scribe for each meeting. If someone was unable to Facilitate or Scribe on their appointed day, it was their responsibility to find coverage.

This helped promote ownership—we were all one team of equals and therefore equally responsible for the team’s success.

Of course, since we are a firm that provides organizational change management (OCM) services, OCM was always on our mind. Design thinking was new for some folks and people are often wary of change. Assigning the rotating roles was a good way to share the workload and learn a skill—we were all in this together!

Another tip is simply to have patience. We were learning a new way of working and change is hard. Trust and respect had to be established and re-established and that process took patience!

At the end of the day (or sprint), it was satisfying to see how we created a product through sheer teamwork—even though remote design thinking was a challenge at times, the final product was worth it!

Have you done any kind of remote design thinking work on your team?! Let us know your experience in the comments!

About Terry: Terry Daffin is an Executive Consultant within KAI Partners. He has worked in the IT industry for more than 30 years and has over 25 years of project management experience. As a public sector consultant in the health care industry, Mr. Daffin assisted in the development and implementation of Project Management Offices that include project management, service management, lean agile and traditional product development lifecycles, and governance processes. He has been an innovation advocate and evangelist for 15 years and has implemented innovative processes for projects that he has been engaged in since 2001. Mr. Daffin currently works as the Project Manager of the KAIP Academy, KAI Partners’ training division and is the Community Manager at KAI Partners’ coworking space, The WorkShop Sacramento.

About Denise: Denise Larcade is an Organizational Development Consultant and Merger and Acquisitions Expert. She is a Certified ScrumMaster, Certified Scrum Product Owner, Lean Six Sigma Green Belt, and is Prosci certified. She has over 25 years of experience in training, development, and leading companies through organizational change management. Denise has worked in corporate retail, technology, and government healthcare and most recently has experience with large-scale implementations nationwide. She currently works as an Executive Consultant with KAI Partners, Inc., providing client support to KAI Partners’ state clients. Denise lives in a 55-acre walnut orchard and enjoys the early morning hours when wildlife is stirring and the many birds are chirping. Since working from home as of recent, Denise has found she enjoys that extra cup of AM coffee without the commute…just her and nature.

By Sid Richardson, PMP

Raise your hand if you’ve run a software project using the Agile Methodology and have run a software project using the more traditional waterfall project management methodology? I’m sure there are many of you!

Having worked in project management for nearly 30 years, I have run software projects using a variety of different methodologies and I can certainly appreciate the benefits that they all bring to the table.

One true constant in life—and in software development—is change, and I’ve seen my fair share. Here’s what I’ve learned along the way.

The ‘80s were RAD

In the mid-1980s, a software development methodology called Rapid Application Development (RAD) began to take off.

James Martin developed the RAD approach at IBM and formalized it in 1991 by publishing a book called Rapid Application Development. The RAD approach was based on working closely with the customer and prototyping solutions quickly to deliver a final product. The intention was that there would be less effort placed on the planning aspects and more on the customer collaboration aspects.

While RAD was not necessarily a true project methodology for software development, I believe it led to an easier buy-in to the Agile project methodology many of us use now.

Meeting the Requirements

When I was working in Europe in the early-to-mid 1990s, there was a heavy emphasis on formal approaches to project management and software projects. This may sound strange—or it may provide flash-backs for some of you!—but I remember a time when absolutely no analysis or design work was allowed to begin until the user requirements (typically volumes of paper in large bound files) were received in hardcopy form with sign-off by senior company executives.

Can you imagine working in that type of environment?

The traditional waterfall approach to software development projects was rather rigid, but I can understand the reasoning—the leadership wanted to have a high level of confidence in what would be delivered.

Fragile Agile

Fast forward to almost 20 years ago and many organizations encountered internal pushback and some challenges with the adoption of Agile as a software development methodology. The common joke thrown around in the middle of an Agile rollout was that it was “Fragile.”

Since the requirements in an Agile methodology are more dynamic, things eventually settled down and as someone said to me recently, “I guess we’ve come into an age of sticky notes and Sharpies.”

Design on My Mind

At KAI Partners, we have recently started using Design Thinking. Design Thinking provides a creative, solution-based approach to solving problems and is also sometimes known as human-centered design or user-centered design. It’s on the side of creative problem solving, which—being a creative type of guy—is why I gravitate toward it.

Design Thinking encourages organizations to focus on the people or the customer—and it’s the people-centered focus that leads to better products, services, and processes.

While it’s not a software development methodology, Design Thinking can be used as a problem-solving tool to accompany almost any software development methodology you choose to use.

Is there a Perfect Approach?

So, with all these different methodologies, is one better than another? Well, it depends on the project at hand!

One of the common drawbacks to the RAD approach of the 1980s was the lack of scalability. RAD typically focused on small to medium-sized projects and teams. Then Agile came along in the early 2000s and, as a lean philosophy, could certainly be applied at an enterprise level.

What I think works best is a blended methodology that combines the best features of a variety of different approaches.

If the last 30 years in project management and software development have taught me anything, it’s that there are components and approaches of many different methodologies that—when combined—can make a robust and flexible way to deliver high-quality, timely products to the customer.

And, considering that a new methodology will likely make its way to the surface soon, we can’t get too comfortable. Luckily, as project managers and agents of change, we are used to the continual cycle of change and it will be up to us learn the new methodology, prepare our teams, and adapt our work accordingly.

Need support on your next project? KAI Partners can help your organization implement the software development methodology that works best for you and your needs!

About the Author: Mr. Richardson’s passion is Data Warehousing, Business Intelligence, Master Data Management and Data Architectures. He has helped Fortune 500 companies in the US, Europe, Canada, and Australia lead large-scale corporate system and data initiatives and teams to success. His experience spans 30 years in the Information Technology space, specifically with experience in data warehousing, business intelligence, information management, data migrations, converged infrastructures and recently Big Data. Mr. Richardson’s industry experience includes: Finance and Banking, government, utilities, insurance, retail, manufacturing, telecommunications, healthcare, large-scale engineering and transportation sectors.

By Nick Sherrell, PMP, MBA, CSM

January is the time of new. We have shaken off the retrospective December and are opening our eyes to new ideas and new possibilities for our careers, our personal lives, our habits, and perhaps even some new hobbies.

This January has a couple extra layers of ‘new.’ Not only is it a new year, but a new decade. On top of that, the term “2020” is a cliché connotation for someone having perfect vision.

Let’s talk about your organization’s vision.

Many clients I work with have a Strategic Plan. It is typically that document found somewhere deep inside their document library that pops up when you are using the search feature to find some other document. It is usually from a year or two ago, and sometimes still contains a ‘Draft’ watermark.

What happened?

All too often, it follows the same path that many of our personal new year’s resolutions take. A great exercise to think about our future with a lot of creative brainstorming, dreaming, and sometimes (let’s be honest here) wishful thinking. We write it all down, even set some abstract goals, and then…life hits! Critical staff get sick (or have kids that get sick). A new decision comes from the larger organization that shakes up your organizational structure. Sometimes those old habits are just too tempting to pass up, just like that dessert case at The Cheesecake Factory!

Here’s how to set up an organizational vision that sticks.

1. Commit to the process by building a team: It is hard enough to set your own personal vision into action. It is significantly harder to put somebody else’s imposed vision into action. Instead of doing this on your own or with a small group of executives, create a cross-functional team from all levels of your organization and have a trained facilitator guide these discussions. People brought into the design phase are given a sense of ownership and commitment to the results. This is not a strategy that is imposed on them, but rather something they have been empowered to help create. Equally as important, this commits you to the process because once you communicate the concept of building a vision to others, you create the accountability to see it through.
2. Set realistic and concrete goals with clear accountabilities: With your team, set 3-5 core focus areas that each have a maximum of three clearly defined and achievable indicators of success. Make these goals stretch goals, hard to achieve and only attainable through dedication and teamwork. They key factor to keep in mind when selecting core areas and key indicators is that less is more, especially in the early stages of creating a strategic culture. The simpler the message, the easier it is to get everyone on board and rowing at the same cadence.
3. Communicate, Communicate, Communicate: Once you have identified the core focus areas and a few key indicators, spread this message like wildfire across your organization! Wherever possible in your communications to staff, tie the message back to your strategic goals.
4. Build and integrate frequent check-ins: This is where most strategic plans fall short and ultimately meet their demise by collecting virtual dust in a document library. Leaders are usually happy to get in a room and discuss strategy. They are usually pretty good at setting concrete goals, assigning accountability, and communicating a kick-off. The challenge is incorporating this into existing leadership meetings and decision-making. Inevitably, a distraction will happen. Prepare for it early by ingraining these goals into a habit. Which takes me to my last point…
5. Make vision an organizational habit: Once these efforts are integrated into your regular work, reward small wins to build momentum and turn strategic thinking into an organizational habit. If you don’t reach a goal, find the positive aspects and momentum and use those as a springboard to challenge the next iteration of goals. If positives are hard to find, then focus on the learning of what did not work and bring these lessons learned into your next strategic planning session.

Does this sound like a familiar scenario at your organization? If you need help putting your Strategic Plan into place—or creating one in the first place!—we would love to help! Contact us today to learn more!

About the Author: Nick Sherrell is a Project Manager with over 10 years of healthcare experience ranging from Quality, Performance Improvement, Technology Implementation, Data Analysis, and Consulting. Nick has worked with organizations ranging from the Sacramento Native American Health Center, Kaiser Permanente, Sutter Health, Blue Shield of California, and The Advisory Board Company. He currently works for KAI Partners, Inc as a Project Manager Consultant on Public contracts with the State of California, most notably with the Judicial Council of California and California Medicaid Management Information Systems. He received his MBA from UC Davis in 2015 with an emphasis in Organizational Behavior and Innovation. He became a Certified Scrum Master in 2018 through Scrum Alliance training offered at KAIP Academy. He lives in Sacramento with his wife, two children, and Golden Retriever Emma. Find Nick on LinkedIn here.

By Tammy Debord, MBA, PMP, PMI-ACP, CDAP, SAFe Agilist & Scrum Master, CSM

Luckily, this isn’t a trick question. Have you ever heard the phrase, “It’s more of an art than a science.”? This holds true for many different endeavors in life and business, including Project Management.

The Way we Approach Problems is Changing

As a Project Management Professional (PMP)® for over 12 years, here is what I’ve learned—think of it as two different buckets of knowledge.

Let’s call Bucket A: “The Science.” This may include:

1. Project Management Certifications (PMP, CSM, SSM)
2. Project Management Frameworks (PMI, SAFe, Disciplined Agile, FLEX)
3. Project Management Process and Artifacts (Project Charters, Agile Release Trains, Six Sigma Flow Chart)

Bucket B: “The Art” includes things like:

1. Building psychological safety
2. Driving innovation
3. Empowering self-organizing teams to deliver valuable solutions

While the science is absolutely needed, without the art, we have to ask: Would we still consider it a successful endeavor?

I have witnessed a shift from only defining success through costs, dates, and deliverables to instead broadening the definition to include delighting our customers, building a high-performing team culture, and criteria that includes more items from Bucket B.

Design Sprints to the Rescue

Intrigued by this shift and how it relates to my work as consultant, I recently signed up for a Masterclass by Jake Knapp called The Design Sprint.

Design Sprints, born out of Google Ventures, is now practiced across the globe as a proven method for problem-solving and launching innovative solutions.

A Design Sprint traditionally runs four to five full consecutive days with a set number of team members who are pulled together to focus on a core problem. The structure follows the path of Design Thinking, which includes: Empathize, Define, Ideate, Prototype, and Test.

At its core, Design Thinking is user-centered and focuses on rapid learning based on human interactions driven through a tailored process that drives to solutions.

5 Design Sprint Tips

1. Show, don’t tell. Facilitators encourage visuals like sketches, prototypes, and dot-voting over traditional meetings where participants typically just talk about ideas. Having a dialogue using an interactive medium helps to eliminate assumptions when people only describe what they mean.
2. Put people first. People oftentimes drive your greatest outcomes or are your biggest barriers. Projects are not inanimate things to manage.
3. Frame and re-frame. How you frame a problem allows you to find the right challenge to tackle. “How might we…?” problem statements allow participants to try many different lenses to a particular challenge.
4. Embrace ambiguity. Sometimes situations won’t be clear and your cheese will be moved—when that happens, stay the course and push through with your team.
5. Context matters. Whether you are in a new organization or another country, every ecosystem has their own culture, language, and norms to which you should recalibrate.

While I did earn a certification to add to my collection (think Bucket A: The Science), what I take with me is that the “art” of running a successful Design Sprint is the same “art” as running a successful project.

It takes a different part of the skills in your toolbox to master both—the best consultants I know have the best toolbox to pull from.

Put Your Skills into Action

A couple of ideas from the Masterclass that I have been able to use immediately in my current higher education consulting work are:

1. Re-framing the problem
2. Understanding context

For example, when developing an application, it is easy to believe the end goal is simply ‘completed functionality.’

By reframing the problem with the user in mind, i.e., “How might we ensure a student is able to combine and transfer their units online between campuses?”, we ensure that what is developed meets the needs of a solution beyond working code.

This could mean ensuring the underlying data needs to be revisited or that a mobile-first user experience better serves the population using the application.

By understanding context, we may discover we need to know more about the upstream or downstream applications that units are coming from or feed into so that the student has a tool that can meet their needs.

By reframing the problem and understanding context, we refocus using an empathetic lens through a technology solution.

These are just a few ways I’ve started using Design Sprint concepts in my work—do you use the Design Sprints or Design Thinking concepts? Let us know some success stories or problem areas—maybe we can help!

About the Author: Tammy Debord, MBA, PMP, PMI-ACP, CDAP, SAFe Agilist, SAFe Scrum Master, CSM started her career in gaming at Sony PlayStation and has worked in several fields including Solar, Higher Education, and Finance in Silicon Valley. Currently she is an Executive Consultant with KAI Partners, working with a public sector higher education client. While not collecting letters behind her name as part of her love of life-long learning, she enjoys watching boxing and following the Marvel Universe of films.

By Todd Wallace, PMP, CSM

Agile methodologies.
Scrum projects.
Continuous and rapid improvement.

These are all phrases you would expect to hear in a Silicon Valley startup, while attending a morning huddle in a shared space office.

You would not expect to hear these phrases while attending a quarterly all staff meeting in “the large conference room on the 6th floor” at a government office.

However, times are changing, and the way work is being done is changing with those times.

What was once a radical new way to manage projects, or “work efforts,” is now seen as a reasonable, efficient, effective, and adoptable methodology to bring into new areas, such as state government.

As opposed to the historically applied Waterfall method to manage projects in state government, using an Agile method allows for earlier customer feedback and course correction.

This helps increase the chances that your project meets the customer’s needs and isn’t outdated before it’s even completed.

While a juggernaut such as a government agency may not be able to pivot as quickly as a small startup, there are still very real gains that a government agency can realize through adopting Scrum into their day-to-day operations.

With the support and understanding from leadership, a group within a government agency can form into a Scrum team, with a Product Owner, a Scrum Master, and a working group.

By breaking up the work that needs to be done into correctly written user stories and a backlog maintained by the Product Owner, the team can accomplish recognizable progress every two weeks.

While Agile was originally created for software development and rapid releases of code, achieving success with Scrum doesn’t rely on being in a software development group.

Notice that that previous paragraph said nothing about technology or software.

Scrum can be applied to any work effort, from process improvement efforts, to reconfiguring the physical assets of a floorplan.

The overarching goal of Scrum is to “chunk up the work,” or break the work down into tasks that can be completed in a timely manner, with value added at their completion.

Scrum projects may seem like tech world jargon, but there is real value in knowing how to manage Scrum efforts within the government sector and there is a real push for government agencies to adopt Scrum in daily operations.

If you work in a government setting, either as a government employee or a contractor, Scrum is a very real change coming to you soon.

If you want to be ahead of the 8-ball and able to walk the walk when your department’s leadership implements Scrum methods, the Certified ScrumMaster course, offered by KAIP Academy, will teach you everything you need to know to get up to speed. You’ll be able to confidently raise your hand in a “fist to 5” saying that you can coach the team to succeed with Scrum!

About the Author: Todd Wallace is a Senior Project Manager with KAI Partners, Inc. He started his professional career as a student assistant in the special projects department of a state agency and worked as a state employee for over 7 years before transitioning to private sector and consulting to state agencies. He has a BS from CSU, Sacramento in Small Business Operations and an MBA from UC, Davis in Entrepreneurship and Strategy. In his free time, Todd loves tinkering on cars and motorcycles and has a passion for innovation.