Effective Solutions Through Partnership

Category Archives: Project Management

Why you Should Document Business Processes

Best Practices, Business Analysis, Documentation, Organizational Change Management (OCM), Project Management, Small Business

By Denise Larcade

One thing I’ve seen in my 25+ years working in change management and business analysis is that documenting Business Processes and supporting documents like Standard Operating Procedures (SOPs) adds value to a business in a variety of ways.

Unfortunately, some believe that documenting processes and procedures is not always the most exciting of tasks, and it’s often put off from one person to the next. Before you know it, the documented process for a task may be severely outdated—or nonexistent.

A lack of documentation can reduce efficiency of your business if, for example, someone goes on vacation. The back-up who’s covering for them should have access to the Business Process Diagram (BPD) and accompanying SOPs so they can do the job of the person who’s out. If there’s no documentation, the back-up has no idea what to do. The impact to the business is that while the process may be well-defined and streamlined, if it’s not documented, then time and labor is not utilized efficiently.

A complete lack of documentation can be a major problem if an employee leaves. Without knowing their day-to-day processes, it will be difficult to hire a qualified person to take over for them, not to mention keeping business running in the interim.

Luckily, documenting processes and procedures is not a daunting task. Businesses of any size can and should document their process. KAI Partners, a certified small business with fewer than 100 employees, regularly documents its processes and procedures.

When starting out, a good rule of thumb is that each WHAT documented in the BPD should be supported by some documentation on HOW (oftentimes an SOP). Further, when the Business Processes are updated, the accompanying SOP should be updated at the same time.

For example, if the diagram step in the BPD states, “Create Invoice,” there should be a manual/guide, SOP, or job aid detailing how to create the invoice. If today the invoice is created on a Mac and tomorrow it’s changed to a PC, the step in the BPD may not change, but the supporting documents will.

So, what do you do once you’ve documented your Business Processes? Stick them in a drawer and forget about them? No!

Depending on your current business state, you should look at your Business Processes quarterly, semi-annually, or annually. For mergers and acquisitions, I recommending looking at your processes quarterly. If your business is not going through a major change, you should check in with your Business Processes every six months or every year.

When you do regular audits of your business process, you’re checking for:

  1. Accuracy.Is everything the same, or have you made any business changes that should be updated? Think about the scenario above—if the software used to create the invoice is inaccessible due to a licensing issue, a work around may need to be created to keep the BPD current. If the work around does not have a solution date and may be a long-term work around, you should consider updating the BPD to reflect that. (Another reason why regularly-scheduled reviews are valuable—it forces the business owner to address something that was supposed to have been fixed by a certain date.)
  2. Improvements. Is there a way you can improve or streamline the process? What steps no longer need to be done or how can we automate? Perform a cost analysis to determine which step is most efficient.
  3. Future state. What may the future of this process look like? Look at how is the industry shifting or how have other organizations changed. If there’s a new system the industry is using, assess the initial cost to stand up using a new system, as well as the cost over time to change to the new process. This information will be helpful in the future, as changes start making their way down the pike.

I recommend every business—large or small—regularly document and update their processes and procedures. For those who are on the fence, just remember that while eliminating processes may eliminate roles, streamlining a business process means you can now put people in roles that need more attention. This will help your business running at its most efficient.

About the Author: Denise Larcade is an Organizational Development Consultant and Merger and Acquisitions Expert. 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 one of KAI Partners’ state clients. Denise grew up in the Silicon Valley and relocated to Utah and Idaho before recently returning to her native California roots.

Planning for Test Data Preparation as a Best Practice

Best Practices, Data Management, Project Management, Systems Development Life Cycle (SDLC), Testing

By Paula Grose

After working in and managing testing efforts on and off for the past 18 years, I have identified a best practice that I use in my testing projects and I recommend it as a benefit to other testing projects, as well.

This best practice is test data preparation, which is the process of preparing the data to correlate to a particular test condition.

Oftentimes, preparing data for testing is a big effort that people underestimate and overlook. When you test the components of a new system, it’s not as simple as just identifying your test conditions and then executing the test—there are certain factors you should take into account as you prepare your test environment. This includes what existing processes, if any, are in place to allow for the identification or creation of test data that will match to a test condition.

A test case may consist of multiple test conditions. For each test condition, you must determine all the test data needs. This includes:

  • Input data
  • Reference data
  • Data needed from other systems to ensure synchronization between systems
  • Data needed to ensure each test will achieve its expected result

Planning for test data preparation can greatly reduce the time required to prepare the data. At the overall planning stage for testing, there are many assessments that should be conducted, including:

  • Type of testing that will be required
  • What testing tools are already available
  • Which testing tools may need to be acquired

If, at this point, there are no existing processes that allow for easy selection and manipulation of data, you should seek to put those processes in place. Most organizations have a data guru who is capable of putting processes in place for this effort—or at least can assist with the development of these processes.

The goal is to provide a mechanism that will allow the selection of data based on defined criteria. After you do this, you can perform an evaluation as to whether the existing data meets the need—or identify any changes that must be made. If changes are required, the process must facilitate these changes and provide for the loading/reloading of data once changes are made.

One word of caution concerning changing existing data: You must be certain that the existing data is not set up for another purpose. Otherwise, you may be stepping on someone else’s test condition and cause their tests to fail. If you don’t know for sure, it is always better to make a copy of the data before any changes are made.

About the Author: Paula Grose worked for the State of California for 33 years, beginning her work in IT as a Data Processing Technician and over time, performing all aspects of the Systems Development Life Cycle. I started in executing a nightly production process and progressed from there. As a consultant, Paula has performed IV&V and IPOC duties focusing on business processes, testing, interfaces, and data conversion. She currently leads the Data Management Team for one of KAI Partners’ government sector clients. In her spare time, she is an avid golfer and enjoys spending time with friends, and playing cards and games.

Consulting Survival 101: A Project Manager’s Perspective

Best Practices, Managing/Leadership, Project Management, Project Management Professional (PMP)

By Jamie Spagner

Those of us who have worked in the corporate world—or any type of workplace, really—for an extended period of time know that longevity is not a guarantee. Your job within a company may change due to corporate restructuring, personnel/job role updates, or any number of other factors.

A silver lining may be consulting. For many people, consulting is a logical step to extend a successful career. If you have worked in project management positions throughout your career, transitioning to consulting may be able to provide you more freedom and flexibility, as well as the opportunity to offer your expertise to the people and organizations who need it the most.

It’s easy to believe that your decades of experience and the various letters—PMP, CSM, SHRM, etc.—after your name will be all you need to prepare for this exciting new chapter. Of course, it’s not always so simple.

After 15 years in the corporate world—and six of those years consulting—I’ve discovered some lessons that most consultants learn the hard way:

  • Do not take things personally: As human beings, we are emotional. One of the best things I have done to improve overall satisfaction in both my personal and work environments is learning not to be governed by my emotions. As a project management consultant, part of my job is making recommendations; sometimes these recommendations are followed and sometimes they are not. Either way, I try to be more logical and less reactive to the way a situation makes me feel.
  • Humility over hubris: There will be times when you know more than your client, but boasting about this is rarely a good idea. As consultants, we are teachers, not show offs. Timing is everything—use your intelligence to know when to show your intelligence.
  • Practice patience: Organizations move at different speeds and as a consultant, we advise, but rarely get the chance to set the pace. Be patient and stay engaged—this way, you will have more impact ensuring the final decisions your client makes are the ideal.
  • Trade in your ‘Nos’: As a consultant, you should be prepared to offer an alternate solution to your client, rather than immediately telling them ‘no.’
  • Champion your client:Consultants should support and champion our clients’ successes, not take credit for the wins. Remember, when people say a home looks lovely, it’s the homeowner who takes the credit, not the architect.

Practicing these tips may not guarantee your success in the consulting world, but they may help keep your sanity, and, quite possibly, your job. Remember, these are just recommendations, so use them or don’t—I won’t take it personally (she said, taking her own advice).

About the Author: Jamie Spagner is an Executive Consultant for KAI Partners, where she works as a Project Manager for a public sector health care client. She graduated from California State University, Sacramento with the Bachelor’s Degree in Communication Studies/Public Relation. She is a loving mother of a teenage son named Wyatt. In her spare time, she enjoys shopping, spending time with family/close friends, and working out.

How to Use Problem Statements to Solve Project Issues

Best Practices, Issues and Risks, Problem Statements, Project Management, Project Management Professional (PMP)

By Stephen Alfano

Who doesn’t have problems? Now, a real question: Is there a simple, surefire, and quick way to break problems down?

Answer: Problem statements.

A problem statement is basically a short, yet compelling description of an issue, or set of issues, that must be resolved. It’s used by problem-solvers of all stripes—from research scientists to project managers to postgraduate students—to drive an effort from beginning to end to ensure and validate an anticipated outcome (not a problem with a well-written problem statement!).

How do you write a problem statement?

I recommend carefully breaking the problem—and the undesirable world it lives in—into three basic components:

  • Vision – This is the description of the anticipated (desired) outcome. Think of it as a view of the future with the changes that will result from the issue(s) being resolved.
  • Issue(s) – This is the description of the problem using a narrative derived from real-world experience (e.g., use cases or test results). It’s usually only a couple of sentences in length and straightforward and concise in tone and manner.
  • Method – This is the description of how the problem (and issues therein) will be resolved. It’s often prescriptive language—sometimes filled with jargon—that helps the problem-solvers map out their path to success.

Of course, there’s a great deal of background detail and mitigating factors that must be condensed to create those three basic components. (We’re talking about a scaling down a small mountain of data and accompanying data analysis into a couple of paragraphs.)

Truth be told, problem statements can be problematic. The input isn’t always neatly packaged. It often comes from structured and unstructured sources that need to be identified, categorized, prioritized and, in some cases, synthesized to establish the following:

  1. the root cause of the problem
  2. the known consequences of the issues that users (and key stakeholders) both up and downstream face
  3. the ill-effects associated with the known consequences
  4. the myriad assumptions and constraints (the pros and cons) within the method used to resolve the issues

Above all, problem statements require persistence and patience. Distilling and editing the content to be clear and concise takes rigorous work—and lots of practice using a tried and true template.

Below, you’ll find links to some of my favorite problem statement templates and best practices:

How do you think problem statements could help your project mitigate issues and achieve success?

About the Author: Stephen Alfano is an Organizational Change Management Consultant and Communications Expert. He has over 25 years of experience leading and managing internal and external marketing initiatives for both private and public-sector clients. His résumé includes providing both new business and business process improvement services to Apple, American Express, AT&T, California Department of Transportation, Chevron, Entergy, Levi Strauss & Co., Louisiana Office of Tourism, Mattel, Microsoft, Novell, SONY, Sutter Health, and Wells Fargo. Stephen currently works as an Executive Consultant with KAI Partners, Inc., providing change management and communications expertise and support services to California State Departments.

Leveraging Lean Startup and Design Thinking Startup Sac Event Recap

Agile, Conferences, Event Recap, Government, Leveraging Lean Startup and Design Thinking event, Project Management, Sacramento, Small Business, Startup Company, Technology, Waterfall


Picture Credit: Startup Sac

By Terry Daffin

The Death of the Traditional Product Development Lifecycle

When we think of innovation, we typically think of product innovation. The tangible things we use on a daily basis go through massive change in one’s lifetime.

For example, the smartphone: Does anyone remember using a rotary phone that had to stay plugged into the wall? What about music? Does anyone still buy or play LPs? Maybe the historians, a few collectors, and the staunch laggards of society still have these items around, but they have almost totally been forgotten.

Process and methodology also experiences periods of innovation. The assembly line revolutionized the manufacturing industry over 100 years ago. Kaizen was introduced in the 1980s as an innovative improvement for manufacturing and beyond. The tech industry has certainly seen its fair share of technology products.

The process for developing those products is also changing. The traditional methods for product development is far too laborious to keep up with demand and often does not meet the needs of users once the product is complete. Private industries and even some public sector departments have move to more innovative processes and methodologies to meet the demand.

I recently attended an event sponsored by Startup Sac. The event, Leveraging Lean Startup and Design Thinking, featured presenter Jake Elia, Bamboo Creative’s Head of Products and Technology.

Jake delivered an impressive presentation and provided many examples of his own startup experiences, as well as example of other startups to accentuate points along the way. I was intrigued by his description of his own life path as a “lean startup” and pivoting when needing to do so.

I started to think my own career path and compared it to the product lifecycles I’ve used over my 30-year career in the industry. Has my life/career mirrored a traditional waterfall development lifecycle? Maybe to a certain degree, but here is what I’ve come to know about life: It doesn’t follow any set process or plan. You have to be ready to make a change when the plan falls apart.

Don’t get me wrong, I’m not saying all plans fall apart, but even a minor deviation in the plan creates some sort of change that may alter the direction of the original plan. That is also the case with product development. The big difference between the traditional development lifecycles and today’s more agile or lean lifecycles is the speed in which product builds, feedback, and changes in direction occur. The increase in “speed” can be attributed to several changes/innovations in the traditional development lifecycle process itself:

  1. Clarity of the problem being solved
  2. Frequent customer involvement and feedback
  3. Simplify the minimum viable product (MVP)

In their own way, Lean Startup and Design Thinking both take into account these three factors. So, how can you use them in your next product development project? Here are my takeaways of the presentation:

Lean Startup

The Lean Startup is a methodology and book written by Eric Reis about his experiences with startup companies. Through his experiences, he saw the need to develop and document a methodology to share with others. I recommend The Lean Startup be on the reading list of anyone who has vision with a solution to a problem and a notion to engage in a startup.

According to Reis, the lean startup “provides a scientific approach to creating and managing startups and get a desired product to customers’ hands faster. The Lean Startup method teaches you how to drive a startup … and grow a business with maximum acceleration.”

The model is simple: Build, Measure, and Learn. Here’s how it works:

  • Starting with a vision or an idea for how to resolve a problem, you create a hypothesis on how the solution might resolve a problem. This step is the clarification of the problem to be solved.
  • Then you build a minimum viable product (MVP). Your MVP should focus on the main or most important problem to be solved. Know that there may be many problems to solve which means many build iterations. Resist the urge to solve all problems with your MVP.
  • Next, you must develop measurable metrics,present to customers who have this problem, record customer feedback, and use the data to learn something about your solution.

The key is using the data to make sound decisions about the path forward. Be brutally honest with yourself and the problem you are trying to solve. The data should provide you with the information to either continue down the path you are on or pivot with a different idea. You don’t want to waste time building something no one needs or wants.

The model looks like this:

Picture credit

Think of your solution to a problem as an experiment. Experiments are valuable not only to prove your hypothesis was correct, but to prove your hypotheses was incorrect as well.

Design Thinking

According to Stanford Graduate School of Business, Design Thinking is a “user-centered way to conceive and create a successful product.”

The Design Thinking model is similar to Lean Startup, however the customer interaction is at the beginning and may be a more beneficial method to use when your customer has known problem.

The model is simple and is meant to be more expedient than a traditional model because it is also iterative.

The phases of Design Thinking include Empathize, Define, Ideate, Prototype, and Test. The model looks like this:

Picture credit

  • The Empathize and Define steps are critical to making crystal clear the problem to be solved. The interviewer should probe the customer for pain points. These steps are to get to the root cause of the problem.
  • The Ideate and Prototype steps are to come up with solutions and to build an MVP. Problems are prioritized and prototypes are simplified focusing on the most important problems to resolve first.
  • Finally, Test your solution by presenting to customers and collecting feedback to be used in making the next decision on what to move forward with. Rinse and repeat!

Unlike traditional develop lifecycles, the Lean Startup and Design Thinking methodologies are highly iterative to simplify build cycles and involve frequent customer interaction and feedback to provide data for plan adjustments.

These and other innovative process improvements are becoming more and more the norm. Even the Federal government has recognized this is true in order to meet the demands of the general public. Case in point, the Federal General Services Administration created an office known as 18F to deliver “digital services” in response to the failure of the website that was developed for the Affordable Care Act.

California is also beginning to ramp up its own digital service methodologies as evidenced by the recent contract award by the California Child Welfare Digital Services project to CivicActions for development of the Department’s new system.

The traditional development lifecycle is not dead yet, but it may be on its last leg. How are you pivoting to these innovations and changes in development?

About the Author: 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 has 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 on since 2001. He has worked with the California Medi-Cal Management and Information System (CA-MMIS) division of the Department of Health Care Services, California Franchise Tax Board, Commission on Teacher Credentialing, California Department of Consumer Affairs, California Board of Equalization, and California Department of Water Resources. Mr. Daffin is currently working on a project for KAI Partners to expand an existing co-working organization into an innovation incubator/accelerator focused on connecting innovative start-ups and the public sector.

next page »