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

Track, Understand and Manage Project Risks Before the Squeak Begins

This is proactive project management. One does not need a week-long course in project risk management to identify and plan mitigation for project risks. Grab the threats by the horns, determine if you can avoid them, plan for mitigation/remediation if you cannot. If you wait for a squeaky wheel your risk has already become an issue. Use a Risk Log to keep yourself organized.

Provide Regular Status Updates, Conduct Peer Reviews, and Engage in Milestone Checkpoints

It is key that you – and your key project constituents – understand the health of your initiative. Tracking status that is forward-looking is an excellent proactive practice that helps you and your stakeholders. Peer reviews ensure that your blinders come off and you are made aware of alternatives, issues lurking around the corner, or areas outside your expertise. Engaging sponsors in milestone checkpoints ensures that they are up to date on where you are at and are aligned on what it will take to move forward.

Assess a Holistic Portfolio of Business Initiatives and Prioritize the List Across User Groups

If you examine your portfolio in segments or as projects come in one by one, you may be setting yourself up for unnecessary project stops and starts. And, if leaders try to commit to delivering all initiatives that are labeled urgent, the organization may sub-optimize the assignment of scarce resources. Leverage a whole-portfolio assessment method that can objectively provide your decision leaders with appropriate information to prioritize.

Flexibly Adhere to an Established Governance Model That Ensures Phase Deliverables are Complete

Project life cycles vary and depend on the type of project. Establish a framework and leverage it accordingly for the type of project you are doing. Do not abandon your framework and miss key hand-offs, decision points, or phase gates. Flexibly applying your rigorous model will proactively enable you to meet the needs of each project.

Manage Expectations Proactively

Tell your stakeholders what you are going to do. Drive for alignment. Be open to course corrections. Share news, both good and bad. Keep the appropriate people up to date. That is being proactive. 

If you keep the worrisome things in the shadows, which then turn to issues, your sponsors and key stakeholders may not appreciate your management by damage control approach.

Proactive Impact Management

Stay on top of action items and issues. Know when each was raised, by whom, and by when they should be completed or resolved. Losing track of these key data points may have you back on your heels when someone comes to seek clarification. Stay out of crisis management mode and be forthright by recognizing issues and steps that may not have been in your original plan. Manage them effectively and you can be your project’s hero.

In conclusion, this is not an exhaustive list of proactive ways to manage your projects. However, this list is a good place to start if you are feeling lost.

Want to know more ways to proactively manage your projects and programs? Let’s connect!

Schedule a meeting with Carl Manello or connect with him on LinkedIn to learn more.

The post 6 Steps to Proactively Manage Your Projects + Programs 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..

Don’t reinvent the wheel, just realign it.

–  Anthony J. D’Angelo, founder of Collegiate Empowerment

In the face of challenging project delivery, and the critical need to grow, evolve, and improve, practitioners do not always know where to turn to improve their capabilities and processes. Lacking other guidance, some organizations try to achieve an improvement approach through internal consensus building. This is certainly a method that encourages everyone to get along; however, it is not always the best way to move forward.

Well-meaning leaders may assemble teams of participants who may lack relevant experience or insight. In an effort to make up for the lack of background and knowledge, an organization may engage in extensive research or waste critical time trying to ‘figure it out’ on their own. Sometimes that research may include reaching out into the ether of the internet and utilizing downloadable, generic templates and processes.

Watch Out for Generic Process Templates

Unfortunately, these downloadable, generic templates will not help the situation. Inventing an answer through consensus will not make the cut either. So, what is the answer? At Transforming Solutions, we are in favor of leveraging proven processes and methods. Our proven practices have been successfully leveraged repeatedly. We believe this proves them valuable.

Processes and methods must have repeatedly worked in a variety of situations – this makes them proven practices. To be sure, practices should be tailored to fit an organization’s purpose. Aligning or tailoring these practices is key. However, the tailoring exercise should be more than rearranging the steps, changing out corporate logos, and swapping the order of stoplights on a status report. The process of tailoring requires insight, experience, and even battle scars.

If it Isn’t Broke, Don’t Reinvent it

Here is an example of an organization that chose to invent a process and was unsuccessful:

A multi-year, multi-tens-of-millions of dollar program needed to track budget and schedule. Instead of using proven cost performance index (CPI) and schedule performance index (SPI) methods, the program team invented their own versions of these global standardized mathematical equations. This was analogous to saying “Einstein’s equation of relativity doesn’t work for us, so we’ll make our own version”. 

The project schedule was laid out in immense detail but was poorly managed and provided a false sense of security. Backing a plan into the desired result of the designed math was difficult. On top of this, the plan did not provide easy-to-understand insights to progress. Due to the poor design of the schedule and the ‘invented algorithms’, the program team regularly spent several ‘man-weeks’ per month generating revised cost and schedule numbers. The reporting was done even though it was relatively well understood that the numbers did not represent the real state of program progress. The invention of non-proven tracking methods impaired the project.

Did They Do it on Purpose?

You may wonder why an organization would choose to use tracking methods that required them to reinvent the process (rather than realign it), especially when they were falling behind and overspending. Finding the true issue in the schedule and budget was made more challenging by the customized math. As a result of this similar-but-different approach to tracking status and cost, the true reality of the program was hidden. This makes one wonder: was this creation of alternative methods done on purpose? The entire management team was aligned to the ‘invented’ approach. Groupthink had already done its damage. Against coaching from consultants, including yours truly, several finance analysts, and some vendor partners, the management team exemplified an emperor with no clothes situation. Sure, it ended up gaining the company more money, but it was as if they were purposely hiding the truth.

After more than a year of reporting status in an artificial way, the management team still did not fully understand what was needed to complete the large-scale effort. This was the case despite the abundance of resource function graphs, risk logs, engineering drawings, and project critical path representations generated every month. For this program, a lack of good methods and a lack of transparency impacted effectiveness.

Tailor it “Fit-for-Purpose“

Proven templates, processes, and methods should be leveraged and customized to meet your needs. When leveraging standardized templates, it is crucial that you work on customization with someone that has experience. Engaging experts will help assure that you do not leave out key data points. Experts understand which data is the most impactful. Great design celebrates the marriage of form and function. Think about the value of a status report with proper health metrics. Consider an issue log’s value with appropriate aging data, and assess a risk log with line-item currency valuation of risk. Reinventing does not always prove useful. Why invest the time, money, and cycles of trials to reinvent a process that already works well? Instead, follow Mr. D’Angelo’s adage and realign (rather than reinvent) the wheel.

Mature Your Organization’s Capabilities

If you are looking to mature your capabilities and do not want to waste cycles reinventing, TSI can help you by sharing proven practices for effective delivery, organizational change management, business process improvement, and technology assessments. We will work with you to align our proven practices to your needs, your environment, and your culture. Drop us a line and let’s work together to align a wheel for you.

The post Proven Processes: The Value in Realigning a Wheel 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..

As the world is changing and evolving, organizations are always looking for ways to get more value out of their strategic and tactical initiatives. This aligns with the way TSI views delivery teams: not just as cost centers, but as value centers that benefit the organization. For organizations looking to leverage the value of their delivery teams, TSI suggests the following three efforts. Let’s take a look at each element and the key things to consider in each.

1. Building Project Management Offices
2. Designing and Implementing Portfolio Management Frameworks and Processes
3. Improving Business Analysis Capabilities

Building Project Management Organizations

Project management organizations come in a variety of shapes, sizes, and different functional responsibilities. Some are internal groups that create practices, policies, and standards for managing the projects of the organization. Standards include creating project artifacts, tools, or tool kits, evaluating and prioritizing initiatives and projects, managing project resources and activities, managing project budgets, and aligning the organizational view of projects. This does not mean that all of those involved in the PMO are experts on all areas of the organization, but they are likely the best delivery experts in the organization.

A PMO can improve delivery effectiveness by managing the delivery from start to finish in a consistent manner. Projects are selected based on a defined rubric that aligns with the vision of the organization, rather than on favoritism or a first come first serve. The result is the completion of projects in a way that provides the greatest positive impact for the organization.

Designing and Implementing Portfolio Management Frameworks and Processes

As with a PMO, portfolio management helps organizations select projects objectively. While this may sound easy, I’m sure every reader has an example of an organizational initiative that was heavily influenced by personal or political feelings. Furthermore, it may be hard to decide which initiative is more important if the initiative impacts two different areas, such as HR and order fulfillment.

Portfolio management also includes elements of ongoing project evaluation and decision-making for projects that are not progressing as expected. The focus of portfolio management is on objective decision-making for difficult decisions. Portfolio management creates standards that delivery teams can use as guidelines to ensure projects remain on budget and deliver the expected objectives accurately.

Improving Business Analysis Capabilities

Business Analysis provides an element of effective delivery that may be often overlooked. Every project has a desired outcome. The outcome is driven by the collective requirements that dictate the elements of the project. The requirements may range from building footage to technology to functional requirements, all depending on the focus and type of project.

Having strong business analysis capabilities on a delivery team improves delivery effectiveness by ensuring that the desired needs are captured before beginning the project. The result of ‘getting ahead’ can be reduced iterations and limited delays during implementation or build. While subject matter experts may provide strong support for and recognition of the need for change, they are often not trained for how to elicit, gather, document, and manage the most effective requirements. A strong business analyst will be able to capture and synthesize inputs and create a set of formalized requirements that accurately represent the need and can be translated into development.

Bonus Element for Strong Delivery

There is another key part of delivery effectiveness not addressed above. At TSI we feel this element is key to all of our successful engagements and one we weave throughout our engagements. That element is organizational change management. Without it, even the most well-equipped delivery team may struggle.

Organizations may have completed an objective project evaluation, have a clear plan for managing and controlling a project, and have based their project on a strong set of requirements. However, if they have neglected to evaluate their organization’s capacity for change, their project is destined to fail. Organizational change management ensures that the organization understands the vision and the value of the project, the impact it will have, and the process that will be utilized to ensure that it is successful. If there are elements that will pose a risk to the success of the project, organizational change management helps identify those issues early so they can be resolved and overcome with ease.

Why does strong delivery matter?

Organizations engage in project management efforts every day. Some are very successful. Some struggle. The elements of strong delivery outlined above will help any organization move to the next level of delivery effectiveness. If you are interested in talking more about how TSI can partner with you to deliver projects more effectively, reach out and let’s chat!

The post 3 Elements for Strong Project Delivery Within Your Organization appeared first on Transforming Solutions Inc..