Danger Will Robinson!

B9, the Robinson Robot, “Lost in Space”

Artificial Intelligence (AI) covers a spectrum of technologies. Some of those have been on an upward trend in the last few months. The tech is making a bit of a post-pandemic comeback thanks to the magic of ChatGPT and the financial performance of Nvidia. We remember the excitement back in 2018, when robotic process automation (RPA) was in the news and the top “push” service offering from all the key consulting firms. Five years later, Artificial Intelligence is back with fervor. Is AI really all that great? Why the ups and downs of interest in the market?

The airplane, the Smartphone, Artificial Intelligence

The common denominator for the three items above is that they are all responsible for sea change shifts, not only in technology, but in our culture and the way we live day today. The authors have no doubt that AI is here to stay and will have a significant impact. It will change the way we live and work. However, we do not believe that the change is quite here yet. Globally, we are just testing it out (think more the Wright Brothers than the Right Stuff).

Companies that can afford the investments will continue to experiment. 70% of respondents to an S&P Global Trends in AI survey said they had at least one AI project in production. One of the challenges in trying to leverage these powerful tools is that enterprise data is not as well organized as it needs to be, as noted by Axios in their summary of the S&P report.  If one does not have data, there is nothing for AI to leverage.

Some companies do have good data. McKinsey and Company recently debuted an internal chat application for employees. That is a milestone for AI. However, after tours in professional services firms, the authors know that management consulting firms are comparatively ahead of the curve in terms of well-organized data. They tend to have extensive, well-indexed, and highly managed document repositories. These “knowledge bases” are often the key for global services firms’ ability to share and reuse materials to their advantage. And now the information they contain is critical in the AI race for effectiveness. Unlike McKinzie, most companies do not have well curated databases of information managed by a specialized knowledge management team.

Acquiring good data is not easy. For example, one HR organization we know was going to use a web chat-bot to improve employee experience and improve responsiveness of the HR team. But the team needed key data, decision rules, codified processes and advice, and workflow to feed the chat-bot. Since the team had little in the way of formal documentation, the AI project was scrapped. Leadership estimated it would have taken over a year to build the knowledge base for the AI to inquire against.

Many organizations struggle with data management for more traditional applications, such as operational reporting and business intelligence reports. In a recent post about current state analysis, we discussed that defining data exchange requirements between just two systems is a detail-oriented and time-consuming exercise. The data management challenges for enterprise AI go well beyond this simple example. It is unrealistic to expect most organizations to quickly make the jump to next-level data management capabilities that are demanded by truly impactful AI applications.

Discovering Fire

As if the data management challenges were not enough, there is also a steady stream of ethical and emotional questions to navigate. Some people are worried that artificial intelligence, specifically machine learning, is dangerous. What if the robots (actually, the software) become smarter than us? Won’t they take over? Are we doomed? Consider our species around 350,000 years ago. We began to use fire. Fire was (is) dangerous! However, when used properly, fire added value and helped with human evolution. The answer to “is AI good or bad?” is not a simple yes or no. Just like the use of fire, Max Tegmark, MIT Astrophysist said on the Smartless podcast, it depends on how we use AI. Artificial Intelligence is “still pretty dumb.”  Getting AI to understand the information it consumes and offers back to us is still the challenge that makes this technology hard.

Consider ChatGPT: a well curated source of data (the ‘spark’ for our use of ‘fire’). But its data are not current. The tool quickly parrots answers back to those asking. It just responds with what seems like well-constructed answers. However, ChatGPT does not understand. (Please, do not get us wrong, ChatGPT is a great achievement. But it is not accurate enough to be considered reliable.)

Commenting on the reliability of ChatGPT output, Ben Thompson and James Allworth, from the Exponent podcast, describe it as a “high-schooler essay, delivered with the confidence of a 48-year-old man.” They say there is (or will be) a need for humans to learn how to verify AI-synthesized information. The challenge for organizations will be learning how to do this, how to staff for this, how to build process for this. Part of that challenge may be overcoming resistance from existing staff, who fear that AI will replace them. (We are not going to make a prediction either way on that matter; but we would observe that past technological disruptions tend to create new and diverse types of jobs even as they eliminate certain existing jobs.)

Long path

Whether applied for the greater good, or for unintended evil (see the Industrial Internet of Things article summarizing the plot of The Terminator series – and discussing AI), software that can mimic human thought is a long way off. We first need to clean and organize our data. We also need to develop rules for thought processing that replicates human thinking. We need to come together as a global community and, whether through technology or human intervention, work towards AI outputs we can trust. That time is not here.

Movies like Terminator, Ex Machina, and others spin up our imagination. Meantime, ChatGPT, Alexa, Siri, and Google Search are giving us a legitimately exciting glimpse of what is already possible with AI.

And so, the race is now on to create company-specific versions for employees and customers. Those who succeed in the AI race will be the ones who define the problems they wish to solve, set realistic expectations for what is possible as technology evolves, and acknowledge the people and process challenges they will face. This will be exciting, but not easy. Artificial intelligence is hard!

The post Why is IT So Hard? Artificial Intelligence appeared first on Transforming Solutions Inc..

A problem defined is a problem half solved

Albert Einstein

Have you ever been in that situation where a colleague has passionately described the perfect technology solution, talking about features, cost estimates, or even a vendor who can deliver? The passion and the vision may have been great, but did anyone ask, “what problem are you trying to solve?” If there is no problem to solve, then there is no reason to invest time in a solution. The authors have seen this often: organizations build solutions for problems that do they do not fully understand.

To understand the challenges to be solved, one needs to understand the existing situation (i.e., current state). Yet, organizations tend to balk at the need for this type of analysis. They assume their understanding is complete (when it is not). Nor do organizations appropriately focus on the context of the situations that drive the need for change. A typical protest is that an organization is implementing a new future state, so there is no need to document the current state. The authors believe current state analysis is indispensable to any effective solution definition. While it may be challenging, it is 100% doable.

Why Assessing Current State is Indispensable 

All organizations execute processes. They generate demand, onboard customers, deliver services, and hire new associates. While organizations carry out a multitude of processes over and over, day in and day out, they typically know less than they might think. Processes are often messy. They: 

• cross multiple operational functions 
• have numerous hand-offs among individuals or teams 
• include plentiful, undocumented sub-steps 
• do not take full advantage of automation 

Dozens or hundreds of stakeholders may participate in a process, but rarely does anyone readily understand a complex process end-to-end. In many cases, the end-to-end process is not documented. Without alignment to what is being done today, it is unlikely that effective process improvement is possible for tomorrow. 

A simplistic example on YouTube makes the point about common (mis)understanding of a process. The sandwich example may feel foolish, but it is a useful illustration. Even the most mundane process turns out to have dozens of possible steps. If not documented in plain language, there will be different interpretations. Without clarity of process, then alignment, efficiency, and quality may be elusive.

Not If, but When 

For any significant change, current state analysis either happens up front as part of a deliberate plan, or mid-project as unplanned, catch-up work. We prefer up front and planned. Software selection is a favorite example of ours. Choosing a tool does not include any process, right? One just needs to create a list of requirements and interview vendors. However, requirements come from the work we want to do. The work we want to do comes from a future state. The future state is built on analysis of the current state. Even software selection can be improved by current state mapping.

We are familiar with a company that decided to purchase and implement a back-office accounting solution based on assumptions about how customers would be billed. No current or future state process analysis was done. After ten months and half a million in expenses, the team determined that the billing assumptions were wrong, and that the selected software did not meet the company’s needs. But it was too late, and the company was stuck with the purchased software solution. The team ended up taking a Frankenstein approach (heavily customizing the software into doing something it was not intended to do) to meet their need. Not only did this result in a suboptimal solution, but the heavy customization exposed them to a future technical debt risk (see Why is IT so hard post #2).

It’s all about Context 

As one dives into problem solving, understanding organizational and operational context is useful. Are there new compliance requirements that must be considered? How does the process align with strategy? Are there external processes that have an impact? What are the needs of the constituents that are not being met today? Processes do not happen in a vacuum. Solutions should not be developed in a void disconnected from operations. For example, we talked to one organization that had planned to refresh desktop phones. Before ordering new devices, the company took time to ask how phones were currently being used. They learned that the desk phone refresh was unnecessary. Context had shifted. Many constituents preferred to route calls to their personal mobile devices. Fully understanding the “Why” helped the organization avoid solving a non-problem. 

Taking time to define the organizational context for a change is valuable. It will help to drive a shared understanding, define the voice of the “customer,” call-out strengths, weaknesses, opportunities, and threats; and it can help to set up preliminary solutions. Once this short exercise is complete, effective analysis of the current state is more attainable. 

Workshops Not Required 

Current State Analysis does not necessarily require weeks of effort. The in-person workshop series certainly has its place – but many current state analysis exercises can be done with much less fanfare. That does not mean the analysis should be done in a cursory or unstructured manner. It just means that many problems are limited in scope, and the effort to define the problem is lower.   

But the effort is not zero. Consider the common example of automating a daily data feed from one system to another. Though limited in scope, a Business Analyst would ask many questions. “What fields are extracted from the source system today? How is data quality enforced? How is missing data handled? What time of the day do users need the data loaded into the target system?” And so on.  

This interrogation is just current state analysis. For experienced resources following sound methods, this is hours of work (not days). A skilled Business Analyst paired with knowledgeable subject matter experts (whoever executes the current state process) can make great progress in a short amount of time. The result will be a fully defined and documented problem. Everyone will see the same picture. Stakeholders will be smarter. The future state design will be closer to right the first time. The team will avoid frustrating re-work during the technical design and build. 

Conclusion 

Whether the problem is complex and multi-layered, or quite simple and limited in scope, current state analysis is invaluable. Current State Analysis can be challenging, not because it requires technology skills, but because it requires time and commitment and critical thinking. Current state, even when complex, is knowable. It is a matter of asking the right questions, of the right people, and taking the time to document in a manner that is clearly understandable.

Current state analysis goes best when facilitated by someone with experience, using proven methods and frameworks. But it is not rocket science. Organizations that are serious about building better solutions through better problem definition can develop the capability. As hard as current state analysis might be at times – as one defines the problem at hand – solving undefined problems is impossible. So, keep these seven powerful words handy, and don’t be afraid to use them: “What problem are we trying to solve?” If you do not work to define your current state, you will find that IT is hard. 

The post Why is IT so hard? – Current State appeared first on Transforming Solutions Inc..

People resist change. That has been well established. Scores of papers, blogs, and books have addressed this topic, along with executive coaches, TED-talks, and now even yours truly. When people believe they will lose something of value, or if they fear they will not be able to adapt to new ways, they resist. Sadly, there are no exceptions for information technology-driven change. The downsides? Stakeholders resist new processes and new systems. Adoption is low. Sometimes the projects fail.

When things do not go as planned, people seem surprised. Even when they knew they were introducing change and knew that people resist change, they failed to prepare for it…again!  IT is hard.

In our experience, organizations may talk a good game when it comes to Organizational Change Management (OCM), but too often they fail to act with the vigor and completeness that is merited. In this post, the authors will explore why this may be the case.

When organizations begin transformation projects (or even simple improvements), they tend to focus on the solution: process changes, policy changes, organizational changes, or system changes. They spend less time considering how people must adapt to the change. The authors typically find that project teams are aware of and good at completing the core design and build steps of projects (e.g., requirements definition, vendor selection, and project planning). On the people side (the OCM side), however, we see insufficient time and energy being applied.

THE CHANGE PARADOX

A common project approach is to plow the lion’s share of limited human resources into building a change. Experienced delivery professionals would concede that they should also allocate sufficient resources to ensuring adoption of the change. But the prevailing sentiment is often one of, “We’ll cross that bridge (adoption) when we get there,” – as if every project were a journey of one peril after the next. Only after conquering the first peril (building a viable solution) will the team dare to worry about the subsequent peril of change adoption. Paradoxically, the adoption of a solution will be at risk without OCM, and common thinking says that the buildout of the solution will be at risk with OCM. Which is correct?

The perceived risk is that every resource allocated to OCM is one that is not invested in developing the solution. The thinking is that if the balance of resources shifts too heavily away from the development of the change, the solution will not get built.  If there is no solution, then there is no change to “worry about.”

Both the solution build and OCM are needed. Leaders must allocate time and money not only for building a solution but to promote, engage, and enable solution adoption. They must assume they will conquer all perils and ultimately complete their journey!

HOW TO FIX IT?

Start right away. OCM should be core to any change journey, beginning on Day One of the initiative (don’t wait until later!). OCM does not require extra resources or special certifications. OCM should be an integral part of any initiative that changes systems, processes, or the operational behaviors of an organization.  By ensuring engagement, communicating “the Why,” encouraging participation, and driving adoption, organizations will be better able to achieve their goals. Without this concentrated focus on bringing people along on the journey of change, organizations may find their projects broken.

Be emotionally intelligent. Before the turn of the century, Dr. Spencer Johnson published the short, easy-to-read Who Moved My Cheese. The parable illustrates why “moving cheese” (in this context: within the frame of a maze for mice) is difficult. Behaviors must change to attain the same goals. Methods of work need to change. Attitudes need to change. Change is an emotional journey, and our change initiatives must reflect that reality. OCM helps to focus on the people journey.

Assess change readiness. Transformation projects are typically not easy. Modern technology can be hard; new processes may be difficult; and training is time-consuming. To get at the root of what may be in the way of people changing, organizations can conduct readiness assessments. These simple inquiries can help to establish how ready, capable, and aligned (or not!) an organization is to take on the project and do not require a lot of additional effort. Assessments help to gauge the temperature of the organization: ready or not ready. Once we understand where we are at (by gauging the temperature), we can act appropriately.

Measure the value of OCM the right way. While the full cost of OCM is incurred during the project, much of the value comes over time. Calculating meaningful ROI in the short term based on hard costs alone can, therefore, be misleading. Instead, the authors suggest any attempt at traditional ROI calculations to prove out OCM should be deferred to a future date, after benefits (e.g., lowered operating costs, quicker throughput, improved quality) have had time to aggregate. In the shorter term, the authors recommend focusing on how well the change has been adopted by stakeholders. Measuring stakeholder adoption can be achieved quickly after a change is rolled out by applying various techniques to capture user sentiment, engagement, and enablement.

CONCLUSION

The desire of any organization implementing a change is that the adjustment is fully adopted, and the value is fully realized. That is easier said than done though. However, we must persevere to move forward. A former U.S. president noted, “The price of doing the same old thing is far higher than the price of change.”  Plan for your change, engage your stakeholders, assess where you are at and adjust.  These techniques will make you an effective organizational change manager.

The post Why is IT So Hard? Organizational Change Management appeared first on Transforming Solutions Inc..

We have experience with an insurance company that wanted to take its first steps in a digital transformation. With a goal of improved customer experience square in its sites, the new initiative would overhaul the company’s website and establish a true handheld mobile device presence for the first time. Management was onboard and ready to write the check to drive the transformation over the next few years. The Marketing, Sales, and Finance teams stood ready to provide support. Information Technology was energized.

Then, the chief architect and CIO broke the news: since existing systems were so old and poorly maintained (due to historically insufficient attention to capital improvement), a significant amount of backend modernization would need to be completed before the customer experience work could begin.

The next two years were spent re-coding websites, modernizing integration points with legacy systems, and addressing security concerns. This work was required to lay the foundation for improving the customer experience, that would eventually drive new revenue. Little movement was made on “transformation” during those two years.  Technical debt got in the way and made IT hard.

As part of our ongoing series on why IT is so hard, we continue the discussion with the introduction of technology debt. Tech debt is the implied cost incurred when organizations do not fix problems that will affect them in the future.  There are several types of tech debt.

Constructed Debt: building customizations to packaged software that complicate updates/replacements; or constructing “temporary” solutions without fully understanding the environment or technology. (For example: Customizing a vendor software solution. When new versions are released, the update cannot simply be applied.)

Aging Debt: as systems age they become inefficient, incompatible with newer linked systems, and they should be replaced. When systems are not replaced, they can become debt. (For example, a CFO said that the financial ERP was not broken yet so we could wait a few more years without vendor support before migrating to a current and supported version from this decade). As systems age, they are often more complicated and expensive to replace.

Knowledge debt: in 2002, Sheila was a master coder. She solved all the organization’s problems on the AS/400. In 2021, Shelia retired. She left no documentation; and her code lacked comments, was not structured in design, and could not be reverse-engineered without great effort.

Technical debt examples are everywhere:

• Highway improvements cannot be made due to the debt of crumbling bridges
• Highspeed rail cannot be implemented because of insufficient tracks that have not been upgraded for decades
• An ERP replacement impacted by the debt of legacy software and hardware that have not be sufficiently well modernized, documented, or supported

The ACME company acquired a new business with the intent to integrate operations and systems. Due diligence teams completed their assessment; however, information technology was not involved. Management decided that while not simple, the merger appeared straight forward. When eventually brought to the table, IT’s assessment was that systems integration would not be done so easily:

• The acquired systems, while still functional since being built in 2003, were written in a language that few understand in 2023
• The on-premises hardware of an acquired company has not been updated with the latest system releases and patches (and after the acquisition, the non-IT leadership fired the one woman who understood the hardware)
• There was no documentation of the data repository, making opportunities for combining data into the corporate data lake significantly complex

Why Technical Debt Matters…

Like financial debt, technical debt needs to be paid down. Having too much can suffocate organizations’ opportunities for future investment. Organizations pay interest on technical debt in the form of resources committed to maintaining systems which are outdated but which are nonetheless critical to operations. Eventually, the principal must also be paid in the form of a major upgrade or investment in completely new solutions. This is a hard pill to swallow because the best outcome is generally just staying even. Fixing outdated legacy systems is table stakes. It is like paying off the credit card balance: writing a big check but receiving nothing in return, other than literally zero (as in a zero balance).

The effort to pay down the interest and principal can consume a staggering proportion of an organization’s budget and brainpower. This can be a challenge for any organization. Remediation initiatives become Information Technology’s top priority. Other work is de-prioritized, including revenue-driving initiatives advocated by business leaders with P&L responsibility. Understandably, business leaders become unhappy.

As illustrated by the case of the aging ERP noted above, leaders like return on investment. Upgrading or replacing an ERP ahead of the last possible moment does not increase revenue. Nor do new PC operating systems, refreshed servers, faster networks, or better help desk ticketing (IT Service Management) systems. In short, winning business cases tend to be revenue drivers. Good CEOs understand that cost-centers, like IT, require investment to stay current. But they don’t necessarily know what those investments need to be. That is why they hire CIOs.

…and What Organizations Can do about it

In terms of managing technical debt, a critical skill for a CIO is the ability to communicate, sell, and build consensus. A CIO must be able to convince an operational leader, the senior leadership teams, and/or the board to make major investments that have a zero-revenue return. The CIO and the IT organization are responsible for doing what it takes to keep the technology up to date. Part of what it takes to fix technical debt is to make a persuasive case. Systems need to be upgraded. Aging systems must be replaced before they become “bad loans” and begin to incur unwanted debt. In our experience, strong leadership within IT is a must for avoiding a technical debt crisis.

While fostering strong leadership who advocate for investment in modern platforms is key, there are no magic bullets. To a large extent, avoiding technical debt comes down to good habits and good decisions. Homeowners, over time, replace windows, roofs, and old pipes. Nothing magical about that. It’s just anticipating needs and putting aside money. Admittedly, this simple formula becomes complicated in large organizations with divergent needs from competing stakeholders. Nonetheless, to build good habits, organizations can try the following:

• Educate leadership in information technology through regular briefings
• Carve out capital to begin remediating debt before it is essential to do so
• Adopt principles of no customization and instead rely on configuration to meet operational needs
• Document, document, document
• Keep service level agreements current, software patched and up-to-date

The term Technical Debt was originally coined by software developer Ward Cunningham, one of 17 authors of the Agile Manifesto. Once a modest challenge to prevailing wisdom, Agile methodology is mainstream in the 21^st century. Now it’s time for Technical Debt management to step fully into the mainstream before it becomes a crippling albatross around the necks of companies, universities, and non-profits.

If your organizations is beginning to feel the pressures of Technical Debt (or you want to avoid it altogether), TSI can help you with that. A Technology Assessment is one of the first steps in understanding your debt position.

The post Why is IT so hard? – Technical Debt appeared first on Transforming Solutions Inc..

Organizational Adolescence

Making good choices as a young person can be challenging.  One needs to develop personal values and create a bias for leaning in to one value over another.  Without a foundation of values, decision making can be complicated.  If one needs to be truly mindful in the process, a certain level of self-awareness is needed.  On average, advanced brain functioning is not fully developed until the age of 25. I have seen a parallel for decision making within organizations.

Organizational decision making is often left to a singular leader, or a set of directors.  Typically, executive leaders will come together, each with their own agenda – driven by their own personal and organizational goals – to assess, debate, and decide on the next opportunities.  However, not all organizations have fully developed their internal decision-making skills.  While there are often mission and vision statements, there is typically little in the way of operational support to aid one in making choices that are not singularly motivated.

Don’t read me wrong: I’m not suggesting that all organizational leaders are selfish.  On the contrary, they typically are doing what they feel is best for the whole.  However, if each leader is not assessing choices on the same set of ‘values,’ how can an organization best develop its bias for leaning one way or the other?

How to Start?

One way to begin formulating a decision-making standard practice is with the development of a decision-making policy.  An organization must define a basis for HOW it will make decisions.  The HOW can be defined by the governance levels (which leaders or teams will be involved in the process) and the criteria for making decisions. A next step is to start collecting information about WHAT the governance function will decide on: what initiatives are underway? what projects are waiting in the wings? what resources are available?

In my earlier missives I often characterize these two steps as the need to “rack and stack” decisions.  Decisions address both those things that need to be continued or cancelled and those waiting on the launch pad which require a “go / no go” pronouncement.  An organization may create many racks upon which to categorize its initiatives: strategic, operational, research & development, transformation, or run-the-business.  There are scores of other possibilities (e.g., duration, cost, revenue, breath of organization engaged).  The labels are less important than the agreement of leadership on the need for multiple categories by which to classify their decisions.  Within each of the categories, leadership must also find a method and measure for stacking decisions to define a priority for approval. 

If one can classify and categorize their initiatives – hopefully tightly coupled to their strategy – they will be able to realize long-term success.  Getting to done requires people and process.  Technology can be useful (once process is established), however, no tool will be able move an organization closer to their goal without the commitment of people and a defined process.

Apples v. Oranges

Is it better for the corporation to launch an initiative that will deliver $1,000,000 in two years for operations, or launch a six-month R&D initiative that returns just $50,000?  ROI alone cannot determine the course. For example, the R&D project produces a faster return and will contribute to the growth of operations.  Although it has a lower direct financial return, R&D may be funded first if there is a process and method that allows executives to see their opportunities, clearly articulate the decision levers, and provide support for making objective decisions. 

Will it serve the university better to expand their marketing capabilities to draw in more students and stem the losses of undergraduate enrollments?  Or would it be better to tap further into existing markets by leveraging more financial aid opportunities to remove the barriers of entering post-secondary school?  One approach may have a quicker impact; one may have a bigger economic impact.

Without a values rubric (that contains multiple decision-making inputs) for comparing apples to oranges, organizations find themselves trying to choose between in-comparable choices.

Where to Turn?

TSI relishes the opportunity to help its corporate and higher-education clients solve these challenges.  Our Effective Program Management service offering, which includes portfolio management, addresses the approaches for creating a rubric, collects information about what is in process and what is coming, and supports leaders making decisions based on objective self-aware information of a matured organization.  Our proven practices have helped institutions from coast-to-coast.  If you are interested in hearing more about project prioritization or portfolio management, contact me at cmanello@transforming.com and I can help you see where TSI can support your success.

The post Why Structured Decision Making is Necessary for Organizations Today appeared first on Transforming Solutions Inc..

Nothing is easier than spending the public money. It does not appear to belong to anybody. The temptation is overwhelming to bestow it on somebody.

Unlike President Coolidge’s public money, a project budget does belong to somebody: the project sponsor. And while the temptation may still be there to bestow that budget on everything that comes across a project’s path, the PM must master the practices for managing the spend within limits.

Here are four proven practices that will help to define and manage more effectively.

1. Define the Budget

The basics of a project budget are usually predictable. The major components are resource time & expense and ‘stuff’.  “Stuff” may be furnishings for upgrading a college program’s new social space; software (like ERP and CRM); or contract resources.

Some less impactful but equally important budget impacts are depreciation, taxes, and fees. To determine how to calculate these line items, follow the practices in place within your organization. However, to ensure a robust financial plan, check to see that you have considered the following questions:

• Has risk been appropriately mitigated to avoid significant timeline and cost deviations?
• Has buy-in on the budget been obtained from the management team of those that will be doing the work? In other words, did your estimates come from the right source? Were the right stakeholders appropriately involved in vetting and approving the numbers?  Or did your team pull the numbers out of the air…?
• Are all estimates documented with assumptions to allow for variability and to ensure accountability later in the project?
• Are there vendor quotes?
• For internal employees, have chargeback rates and policies been confirmed for everyone in the resource plan?

These are just a few questions that will help you refine your budget and prevent surprises later.

2. Know Variance Thresholds

Most organizations have acceptable variance thresholds. If a project has been clearly defined, formal variance thresholds for spending (for example, ±10%) may be quite narrow. When there are no formal thresholds, one will need to be proactive.

Clarify expectations with sponsors and be sure to document decisions. A verbal confirmation is insufficient. Whether a sponsor has formal or informal thresholds, set expectations, and document these details for the team so that there is no confusion later. Clarifying acceptable variance thresholds proactively – before there is an issue – is crucial to your ability to control expectations.

3. Define Budget Processes and Tools

This third practice is critical: ensure you have the necessary tools in place for tracking time and expenses. It is important to be able to include actuals, calculations for estimates, and variance for both hours and expense. A tool may be a spreadsheet or a sophisticated portfolio management software component. In either case, make sure that processes are nailed down before starting.

First, setup an easy-to-use budget management tool that will show variances and where the budget issues are within the project. Ideally a tool could be linked with other systems used for time tracking or expenses. However, system integration is less important than a tool that is functional, easy to use, and accurate.

Second, confirm that the tool and processes are in place for all inputs to the budget management tool and that the team knows how to use them:

• Time entry and approval for employees and for vendors
• System and process for invoice receipt and payment
• Overtime approval policy
• Deadlines for time submission

Solidifying these items upfront will help to manage the budget throughout the project and prevent weekly fire drills trying to figure out where the project stands. Once there are a budget, variance thresholds, and processes and tools in place, you are ready to manage your budget.

4. Manage your Budget

It is common for project budgets to be managed monthly. However, a lot can happen in a month or even a few short weeks. By the time one discovers an issue, figures out what to do about it, and makes a change another month may easily slide by.

Good budget management requires weekly attention. Sometimes it may be even more often but, in general, weekly management should keep the situation well in hand. If tools and processes are set up correctly, it should take very little time each week to update actuals.

If the budget has been diligently defined, acceptable variance thresholds are clarified, and processes are properly defined, one can expect excellent insight into the financials. Diligent budget management is straightforward if the proper planning goes into it. The more time you spend on practice 1-2-3 above, the easier that practice 4 becomes.

While the average PM will never become President and won’t have a Congress to help them allocate their spend, every PM should understand their duty to control project funds. As the Japanese proverb says, “Getting money is like digging with a needle, spending it is like water soaking into sand.” Make sure you don’t soak your project and only bestow funds on a well-managed budget.

The post Budget Management – Four Proven Practices appeared first on Transforming Solutions Inc..

A victorious army opposed to a routed one, is as a pound’s weight placed in the scale against a single grain. — Sun Tzu

While I won’t compare weights and measures of ancient China (the “I” and the “SHU” versus the pound and the ounce), I will measure up Sun Tzu’s comment against the weight of managing a successful project. All too often projects are focused on the future. The drive for success is what becomes important! I have fallen into this habit myself, commonly chanting a string of queries: “Where are we at?” “How are we doing?” “What will it take to get us to ‘done’?” These are the core questions for status and moving forward. But what about celebrating our successes?

Like a victorious army, a project team which is in a state of accomplishment, recognition, and celebration for what they have delivered will be more successful than one which plods along unsung and unrecognized. One may even think of this very basic human behavior (the need for attainment and acknowledgement) as one of the drivers for moving toward Agile methods. In terms of short sprints and delivering useable widgets on a regular and recurring basis, the Agile project team and its stakeholders feel a sense of success that is repeatedly reinforced.

I have no beef with Waterfall methods. In fact, I am more comfortable as an “old dog” working in this mature framework. However, as you find yourself working in a more structured phase-by-phase approach to meet the needs of the project, ensure that milestones are built into the plan, recognized, and celebrated.

Too often, project teams reflect on their successes (or missteps) only after the project has been completed. The infamous “Lessons Learned” (or more aptly named post-mortem reviews) are often touted as a key for improving one’s delivery. However, too often these reviews are not conducted. The project is over; the team has disbanded; the next project is underway and there is no time. But even if the reviews are conducted as planned, with all the appropriate participants engaged, is it just too late (citing all the reasons that the reviews may have been skipped)? The project team will soon disband. The product, widget, service has been delivered. The project is being closed and the next one is starting up. There is no time! This post-project approach assumes that the lessons learned will be documented, studied, and brought into the next project. Isn’t this just missing the opportunity for an in-process review?

If instead of waiting for the project to end, should we structure our projects with meaningful milestones that demonstrate accomplishment, that enable us to celebrate our successes along the way (and learn our lessons, good or bad)? I don’t mean typical project milestones that come at the end of a phase — although some phase gates should be celebrated milestones. What if we were to embed milestones into plans that are measurable and worthy of recognition? So, instead of achieving the temporal milestone of “Requirements Complete,” one could instead aspire to a milestone that was more accomplishment oriented. “Accomplished documentation of requirements for CRM in all global regions.” That sounds like a much bigger achievement than “Requirements Complete.” We don’t need a party, or a bonus paid out to all milestone contributors. But a pause to reflect on how we made our mark — presumably on time and within budget — offers us the opportunity to stoke the energy of our team.

The point is simply that there is an enormous advantage that a “successful” and celebrated project team can have over a team that has seen too much time between recognized increments of success. Take the time to acknowledge a job well done for defining the requirements and meeting a critical milestone. The more often we find reasons to declare and celebrate successes, the stronger our teams can become.

The post The Art of Project Management: Celebrating Success appeared first on Transforming Solutions Inc..

“There are risks and costs to a program of action. But they are far less than the long-range risks and costs of comfortable inaction.”

– President John Fitzgerald Kennedy

There are risks everywhere, whether they are identified and addressed or whether they are ignored. It is our job as leaders to make sure that we are mitigating risks, in Kennedy’s words, through action. I have found that one of the most critical and difficult action in Risk Management is the cataloguing of risks.

The challenge is to find effective ways to elicit risks from stakeholders. After all, you can’t manage risks if you don’t know what they are. And while it may seem that the identification of risk should be the easiest part of the process, I have found that stakeholders and project teams do not always understand the concept of “risk.” Sure, now you are thinking, “what are some effective ways of identifying risks?”  Thank you for asking. Here are few ideas to help you get started:

• Reviewing documentation from past projects
• Conducting brainstorming sessions
• Engaging subject matter experts
• Questionnaires or surveys
• Facilitating a “Why This Won’t Work” meeting

Risk Identification Methods

• While the Project Management Institute (PMI) tells that documentation from past projects is like “gold” to a project manager, it is more like the Holy Grail. Reviewing documentation from past projects can be an effective way of uncovering risks, especially if you can get ahold of a risk register from a similar project. However, the challenge with this method is that few organizations store documents in a way that enables re-use. Even when they do, a risk register is not typically one of the required deliverables for the project repository and therefore isn’t always kept with the project documents. If you can find a risk register from a similar project, latch on to it. It can provide a lot of insight into what risks you might encounter.

• Brainstorming is a much more common way to identify risks. As you begin to understand who all the stakeholders are, you can determine how to access their insights and tap into their knowledge. Who are the key stakeholders (i.e., who are the ones that should be listened to most and who know the most)? Who are the most vocal leaders (either as proponents or adversaries)? Prior to scheduling a meeting, set the expectations for stakeholders and get them on your side by explaining what is to come.  How will you run the meeting, what are the types of questions you will ask, and what do you want to get out of the meeting? Getting these individuals on your side may ensure that meetings runs smoothly and that you identify as many risks as possible. During meetings, use any tool to capture and document the risks as they are mentioned. Invite each of the people in the meeting to mention as many risks as they can think of. Prime the pump with a list of risk categories to get people thinking (e.g., resources constraints, technology integration, schedule conflicts) and pre-load these categories on the tool you are using to take notes. Have attendees state their risks in the format, “If X happens, then Y will result.” Encouraging the participants to provide risks in this format forces them to think about the impact of the risk and causes them to self-edit their conceived risks. Gather as many risks as possible to use later in risk analysis and planning.

• Direct conversations with subject matter experts (SMEs) is another method to identify risks. Don’t overlook this easy approach.  As an example, on a project to migrate a client’s email system to the cloud, two SMEs were identified. Both had been on this type of mail migration project before. Working with these SMEs enabled the project to identify the risks that might be encountered. The SMEs were also tapped to help explain how they had managed the risks on their past projects. SMEs don’t necessarily need to be directly from your project team or from your organization. If you are implementing third party software, you can ask the vendor to put you in contact with resources who have implemented the software in the past. Even though not directly connected to your initiative, these individuals can be valuable sources for risk identification. If you cannot get all the stakeholders together in a meeting, you can try a questionnaire or survey to leverage their insights. The object of a questionnaire is to collect as many risks as possible from the stakeholders. The survey form can simply be blank with fields for the stakeholders to complete such as category, description, and impact. Or seed the form with categories so that you get the stakeholders thinking about risks. You can pre-populate categories like technology (is it a new technology?), availability of adequate support from a vendor, and resources limitations. Gather as many risks as possible to use later in risk analysis and planning.

• Another method to identify risks is to hold a “Why This Won’t Work” meeting. The goal of this meeting is to have stakeholders voice their doubts about the project. These doubts often lead to the identification of risks. Invite as many stakeholders as possible; provide them with post-it notes and ask them to write their reasons for why the project won’t be successful on the post-it notes. Gather the notes and go through them with the group, capturing all the necessary fields for your risk register as you go.

In her book Risk Management: Tricks of the Trade, Rita Mulcahy suggests combining several of these methods to ensure you identify as many risks as possible. That’s a great idea if your timeline can handle it. If not, start slowly with a brainstorming session and as you gain momentum and others see the value in what you are doing, try to layer on additional risk planning techniques. This will ensure that you identify as many risks as possible and will ensure that your project runs smoothly. Whichever approach you choose, remember the essence of risk planning is to get the risks out in the open where you can manage them. To paraphrase President Kennedy, do not ask what risk management can do for you, but what you can do to prepare for risks.

The post Five Methods of Identifying Risks appeared first on Transforming Solutions Inc..

Several years ago I read Microsoft guru, public speaker, and author Scott Berkun’s book Making Things Happen: Mastering Project Management.  It was a fun, easy read about how he developed his PM skills (including many “human skills”: Listen to Simon Sinek for 5 minutes on leadership and human skills) as he grew and developed at Microsoft Corporation.

The following paragraph is from his chapter on What To Do When Things Go Wrong. I was struck by how closely his words define what I think the expectations of a TSI consultant are.

Taking responsibility for something doesn’t make it your fault: it means that you will be accountable for resolving the situation.  Many people fear taking responsibility because they don’t want to be held accountable and put at risk for reprimand.  A good [TSI consultant has] the opposite disposition: in matters involving teams, [they] … seek out responsibility and use it to help the team and the project succeed.  If relieving an engineer or tester of fear of blame will get [them] a better solution, or the same solution faster, [they will] gladly take the trade.  If [our client manager] is any good, taking responsibility for a problem may earn [TSI] praise.  By lending real responsibility to the problem, [we] instantly make the problem less dangerous to the project.

As consultants, we are accountable for more than just what our role is defined as and more than the specific tasks outlined in a statement of work. At Transforming Solutions Inc., we are senior, experienced consultants; that is why clients have brought us in. We are not hesitant about stepping up and taking on something that will help our client “get to done” more quickly or more efficiently. We are accountable for our work and the work of our teams – even when we are not the leader of the initiative.

Interested? Take a look at some of our team members.

The post Expectations of a Consultant appeared first on Transforming Solutions Inc..

“Decide what you want, decide what you are willing to exchange for it. Establish your priorities and go to work.”

– H. L. Hunt, — American oil tycoon. February 17, 1889-November 29, 1974

Most of us cannot claim to be in the top ten list of the richest people in the United States. But we can claim to follow their practices and methods and aspire to be as successful. So, if we wish to follow Mr. Hunt’s sage wisdom, how do we decide what to work on? This question plagues all types of organizations as they labor to meet the needs of their stakeholders.

Demand Management is one method. It’s typically used to optimize investment spending, but it can be a great way to help the organization more clearly understand its priorities. I’ve outlined the key steps for successful demand management below:

Step 1: Document all requested needs

Often, a conversation may go something like this: The organization says, “I want X.” The delivery organization (or maybe those holding the purse strings) says, “X is too expensive. We are already busy working on Y. X is not as simple as it looks.” It’s a sure-fire way to drive a wedge. Try the following process instead.

• Hold a brainstorming session where the organization can freely discuss its needs independent from the CFO’s (or CIO’s) constraints.
• Document the essentials in an executive charter and capture key objective data for each need. Determine ahead of time what meta-data is needed for each request.

Step 2: Rank order the list of requests

So many times, when the organization is asked the priority of its needs, everything becomes a “high” priority. Avoid this pitfall by using a prioritization approach.

• Draft objective decision making criteria (e.g., size of initiative, duration, value-add, or other benefits). Gather all key organizational partners together. Equal representation is especially important if there are multiple stakeholders to be represented; often their priorities are quite different. It is crucial to make sure that all groups are in the same conversation.
• Set expectations that the rank order will be a consideration but by no means the rule when slotting projects for delivery. The reason for this will become apparent later in the process.

Step 3: Categorize items to indicate whether additional definition is required

At this point in the process, one may have items ranging from full-scale system overhauls (e.g., a new CRM system) to process changes (e.g., improving the prospecting approach and pipeline), to minor enhancements with existing infrastructure (e.g., update to the website). Categorize each request:

• Category 1: Ready for Estimate – There is enough information to estimate the level of effort required to implement the project.
• Category 2: Additional Definition – Requests representing new functions may require a workup of operational requirements and  functional design details before being ready to estimate.
• Category 3: Strategic – The request is so complex, critical, or strategic that a project or program needs to be established specifically to address formulating the project.

Step 4: Estimate effort

Once an item is ready to be estimated one should document the level of effort required to implement. Ideally this estimate should include all phases of the initiative.

Step 5: Define additional details as appropriate

Before decision makers can consider a project, additional detail may be needed.

• Focus on the “what” in a requirements document
• Focus on the “how” in a functional design

Step 6: Schedule and launch

With prepared estimates, clear scope, and defined milestones, a project is ready to launch.  Initiate the effort and leverage standard approaches for project management to monitor and control your journey.

Step 7: Continue the cycle

Utilize regularly scheduled meetings to review the request list and ensure each project is being addressed appropriately.

• As new items are defined, they should be incorporated into a backlog.
• As request are slotted to launch, change the status to a value that excludes them from future list reviews.

In the late 1970′s, H.L. Hunt’s heirs were locked in a bitter fight for control over their patriarch’s legacy. As those charged with delivering value for the organization, it is our challenge to help avoid bitter fights for control over scarce resources by following proven practices of Demand Management. These tips and tricks may not help to make you rich like an oil tycoon, but they will help you to manage a portfolio more successfully.

The post 7 Steps to Successful Demand Management appeared first on Transforming Solutions Inc..