“Strive not to be a success, but rather to be of value”

As a global practice, project delivery is rife with methods, practices, templates, and training courses.  At Transforming Solutions, we also have a framework for effectively delivering on projects. However, we understand that in the end, it is not about the framework, the certification, or the method of delivery. It is all about providing value.

Several years ago I was privileged to contribute to Dr. Harold Kerzner’s Project Management Best Practices book. Kerzner, professor, and Senior Executive Director at International Institute for Learning (IIL), developed some key thoughts on delivering value. Kerzner has written, spoken, and blogged on numerous topics, including delivering value. I found these seven to be revealing.

I’ve adapted the list from Dr. Kerzner:

1. It does not matter how well or how poorly a project is executed if you are working on the wrong project

Seems like common sense, right? Yet, we see many organizations work on the wrong project or work on a project that their organization is not yet ready for. In an effort to help combat this, we offer approaches for project prioritization and selection. In addition, we can help your organization understand if it is ready for change.

2. Being on time and on budget does not necessarily equate to success

Imagine, you’ve completed your project. You came in on time AND on budget. That is the definition of a successful project, right? Not necessarily. Successful projects should be measured on the value they provide to your organization. Have you aligned to all your stakeholders’ needs? Were all the appropriate requirements delivered? Is the organization set up and prepared for ongoing management of the post-initiative delivery (i.e., are supporting organizations ready to stand up and deliver once the project team goes away)? These, and a host of other questions, should be considered before claiming success.

3. Completing a project within the triple constraint does not guarantee business value.

Related to number two above, what is the end-state the initiative was designed to create? You may have managed well inside the lines of the triple constraint, putting in a new student registration system. However, if students are challenged using the new system and administrative staff cannot get the information they need out of the tool, you are not ready to celebrate yet. The end-state after all was not to “put in a new system,” but more closely aligned with to “enable student registration to be more complete, seamless, and accurate”.

4. Having mature PM practices does not assure business value will be there at the end of the project

Unfortunately, I have worked for too many organizations that invested in very heavy project management processes; however, they are still unable to deliver. One IT organization created a checklist of 140 required project management deliverables. This heavy-handed control culture did not add value to delivery. In fact, quite the opposite. Project managers were so consumed with completing administrative tasks that they had little time to focus on the outcome of the product deliverables.

5. “Price is what you pay. Value is what you get” – Warren Buffet

To paraphrase Mr. Buffet, the project cost is simply the price that you end up paying. The value, on the other hand, is what your organization ends up getting from the successful completion of the project. Do you have a measure for the value of your projects, beyond the cost you paid or the savings you realize?

6. Value is what your customer perceives is worth paying for.

The value of expense is often calculated by doing a cost-benefit analysis. Sometimes value is left out of the equation when one seeks to find the cheapest solution. Before starting an initiative, work to make sure you understand what your constituents are willing to pay and why. A project manager should remember that value is a perception of one’s stakeholders, not how well they think we are doing.

7. Success is when value is achieved

Wrapping it up, one is not done until a value is realized. And, that value is recognized by the stakeholders (not the implementation team). If one attains the nirvana state of delivering value, then it is time to take a moment, celebrate your team, and get ready for your next trial. Since you’ve demonstrated success, folks are bound to come and ask you to replicate it.

At TSI we are always focused on delivering something of value. Remember Einstein’s words above and strive to be valuable. TSI wants to enable and support your success and we are ready to partner with you to deliver the value you need.

Contact us to learn more about getting value from your delivery initiatives.

The post Seven Things to Consider When Delivering Value appeared first on Transforming Solutions Inc..

Companies are using RPA more than ever before due to the benefits of improving productivity and quality of data.  According to a Harvard Business Review survey of 523 executives across 26 countries in a range of industries, 58% say they have started their automation journey with 38% piloting solutions, which is twice as many as the year before (HBR, “How Companies are using Intelligent Automation to be more Innovative”, 2019).

Hopes and Dreams

Several years ago, I embarked on a robotic process automation journey with the tenacity and enthusiasm of a kid in a candy store.  There were so many replicable processes that could be automated, it seemed that the cost savings would be easy to attain. A backlog of processes was generated, the initiative was kicked off with the organization, and the processes were prioritized based on which process would get us the biggest bang for our buck. At the same time, we played with the ‘build vs. buy’ notion and assessed various companies, which claimed expertise in RPA implementation.

Pitfall #1: Vendors Who Claim Seamless and Simple Robotic Process Automation Implementation

The vendors my team assessed had various price structures and they all claimed a return on investment within a year or less. The vendors also had meaty price tags. Something didn’t seem right. So we dug a bit into how these vendors implemented the bots and which were the most used RPA software. Some vendors also claimed expertise in our line of business, but we knew we were too much of a niche market for that to be true. To avoid vendors who were clearly ‘stretching the truth’ and avoid the very high front-end investment required, the company decided to test the waters with internal development.

What we found was that the most complicated part of an RPA implementation was within our own control – standardizing the processes we want to automate. Once we realized this, we leveraged our existing development team to learn the automation software. At the same time, we took a hard look at our backlog to thoroughly vet which processes were truly straightforward and which ones required more polishing.

After clearing this initial hurdle, we got to work on our first use case.  We knew it was a big fish to fry, but it would potentially result in a half-million dollars in cost savings by the end of the first year. The process was documented and recorded and the bots were developed and deployed. But a few weeks later, something happened that we weren’t expecting.

Pitfall #2: Relying on Applications outside of your Control

Pitfall #3: Going After the Big Fish Without Practicing on Little Fish

The problem was that we were relying on a 3^rd party website to process our transactions (which was part of the manual process). Once the site realized we began using a bot, they informed us that they discouraged the use of bots on their website. Instead, they suggested we use their application programming interfaces (APIs) instead to accomplish the same task. Unfortunately, several months and thousands of dollars were wasted on a set of bots we could never use again. Now we were several months behind in realizing our cost savings because we had put forth efforts on obtaining the big fish. There was clearly a lot we did not know about RPA. We did not address the unknown unknowns and we did not start with smaller processes to test the waters first. We took these lessons to heart. Going forward we pivoted from automating processes that used external applications and focused on prioritizing processes within our own internal systems.

The People Factor

There are non-technical factors to consider when implementing RPA too. One should plan how to get the buy-in from leadership, as well as how to handle the organizational change management aspects. Especially, when people may fear automation could take away their jobs.

Pitfall #4: Communicating robots as a Cure-All Without Articulating What Makes a Successful RPA Candidate

I did not have a problem communicating the RPA idea to the internal leadership team. Everyone was quickly on board. The question was more around, ‘Where do we start?’. I pitched an approach explaining what RPA can do, example timeframes, and likely ROI. More importantly, I shared what makes a good candidate for RPA: a process must be standardized and not include any subjective decision-making. Being transparent with what RPA cannot do is just as important as sharing what RPA can do.

Pitfall #5: Not Addressing People’s Underlying Fear of Job Security

As we vetted the candidate processes for RPA, we needed to engage the people who performed the daily work that was to be automated and their management. At first, we had a misstep: we were not clear with associates that they were not to be replaced by robots. Without this warning, rumors started, and people began to fear the “Coming of the Bots”. When we clarified that we did not plan to replace anyone, but that we planned to remove the mundane repetitive tasks from their daily workload, we saw more engagement (and relieved workers).

Navigating Forward

Costs were incurred through the learning process to be sure. We learned as we went. We spent the necessary time and resources to thoroughly vet our processes. We made the decision to build internally. All these steps helped us save over $1M in the first year. Most of those savings came from not outsourcing the RPA development work, and development is the easy part.

My advice is to spend the time doing your homework on which processes will be the best candidates and start off with small fish robotic process automation candidate processes. Use a quick sprint method to prevent costly throwaway work if a bot does not prove to be successful. Be clear and transparent with both leadership and the individuals impacted by RPA. On top of this, be sure to explain how RPA is not something to be feared, but something to embrace. After all, improved productivity means more time to focus on higher-level activities.  

About the author: Alyssa Moy is a Senior Director, Product Strategy & Management at Option Care Health and a member of TSI’s Leaders’ Forum.

The post The Reality of Applying Robotic Process Automation in an Enterprise appeared first on Transforming Solutions Inc..

“All the News That’s Fit to Print”: slogan for The New York Times

Status reports and meetings are killing our project teams. Whether it is a ‘crazy Tuesday’ – an entire day consumed by status reports and review updates – or an on-the-spot visit from parent company management, which drives the operational team into a half-day meeting to prepare status, we seem to have lost the meaning inherent in “status”.

The Reality of a Status Report

A status update cannot take the place of day-to-day management. Do not use reports to fill in the holes of missed information. For those who cannot run a project, but want to steer it, status is no substitute. When those who ‘need to know’ want an update of activities, they should not simply ask for a status report.

Okay, let me back off that a wee bit. Management is management. They can ask for whatever they want. However, they should understand the impact of their ask on the delivery teams.

Status, like the New York Times motto, is about printing the news that is fit to print. It is not about printing all the news that fits (herein I could site an example of a 160(!) page ‘status update’ created for the US Department of Defense). I understand that management cannot be in each project’s operational meetings. Leaders have a business to run. I believe that management must find a way to become more engaged (if that is what they want) rather than to ask for multiple status reports or review sessions per month.

For example, it seems a bit taxing on those delivering initiatives to be required to prepare and speak to four weekly status updates, one monthly update, and one quarterly status update all in the same month. That is six status reports in four weeks! If management understood that it took multiple days of effort from several people to create those reports, they might loosen the requirement to save time.

So, you say, how could it possibly take multiple days to create a status deck?

Well, here are some reasons:

1. The requested information is so detailed that it requires creating new methods to share data, that otherwise would not be needed by the operational delivery team.
2. Systems for generating status updates are either incomplete, held together by baling wire, or include multiple manual workarounds. What appears to be a simple management request (for example, “show me your burndown chart”), ends up being a ‘make work’ exercise…each week!
3. Formats and requested content change week-by-week and month-by-month. When a new management player is added to the mix, they may request a new view of the data (see #2 and repeat)
4. The concept of ‘as of date’ is lost. So, the report ‘as of’ Friday is reviewed, edited, and commented on Tuesday. It is believed that for status to be routed through the organization it needs to be made current. Tuesday then becomes the update day for the deck created on Friday, and so on…

When there is a lack of trust between those doing the work and those receiving the information, status updates become way too detailed and way too time-consuming (and that means extra money being spent on non-value-added work). In some cases, the project team must engage extra resources just to keep up with the reporting requests. If management can learn to trust their team, status reporting can return to summary-level information.

The Devil is in Too Much Detail

Furthermore, when status decks include an overabundance of detail (crammed into tiny fonts to meet the one-page requirement) one might begin to worry. Have we lost the forest for the trees? We see each tree, branch, and leaf in such detail. As a result, we may lose sight of the forest (the overall initiative). Be cautious of preparing status that seeks to represent everything that everyone is doing all the time. It is okay to provide a summary or overview. (Note: some projects may be so far in the red that they require remedial help. Multiple status reviews, however, are NOT the answer.)

Status should provide a point-in-time view of where an initiative is at. It should not be used to replace the operational delivery of the initiative. If the status is used for the latter, it would be more time and cost-effective to replace the project team with one that is trusted.

If you are looking for more operationally effective ways to deliver status, we’d love to connect!

The post The Truth About Status Reports and Product Delivery Teams appeared first on Transforming Solutions Inc..