One Easy Technique to Avoid Barriers to Software Project Progress

One Easy Technique to Avoid Barriers to Software Project Progress

Without understanding the whole context of all the work required for a technology project, the risk is high that a key component is overlooked which later shows up and slows or even stops progress. The overlooked component not only can negatively impact estimated completion date and budget but can also impact the project teams’ morale.  

The purpose of this article is to explain a simple diagram to create at the beginning of every project. This context diagram helps clarify complex relationships, workflows, and processes and aids in project planning with a visual representation of several variables to consider beyond mere configuration.

Experts in Microsoft, Oracle, ServiceNow, and so many other applications will say how quickly they can configure their software to meet any business needs. Configuring a software application is typically quick. However, we need to be aware and plan for the many other variables that impact the speed, budget, and successful completion of a technology project.

I was managing a project for a large Oil and Gas Services company. The objective was to provide technology for field service personnel to be able to generate sales quotes, deliver  parts and services, and generate invoices with supporting documentation more efficiently.

Each time we met to collect requirements, the Senior IT Director would say, “We can do that in 3 weeks with Salesforce.”  My project manager alarm went off.  Many software applications, like Salesforce, have exceptional configurability, and are truly powerful for improving business processes. However, I have yet to encounter a single project able to go at the speed of software configuration. This project was no exception.  

With valuable input from domain experts, I sketched a high-level context diagram that quickly brought the elements of complexity into the open. The diagram served as a catalyst for discussions. We addressed the legacy systems integrations required, and the data residing in those systems, including the widely recognized issue of incomplete and inaccurate data. Consequently, we added milestones to the project timeline and included the associated resources and budget. These milestones included tasks to clean up data and ensure secure, reliable integrations that adhered to well-defined business rules between the new application and legacy systems.

Following is a sample context diagram. It fits on one 8X11 sheet of paper. While the example is not specific to any one project I’ve managed, it includes the three main elements: inputs, project scope, and outputs. Placing the three elements in the correct order and correct buckets highlights hidden work that arises from assumptions and overlooked complexity.  

1.  Inputs - On the left are inputs to the new application.  Some inputs may be manual and some flow from other systems. We can quickly determine if any one of these inputs could potentially become part of the project scope, timeline, and budget to reach our business objectives. Below are two of the most common components of work overlooked.

a.      Data – The data residing within legacy systems, considered the primary and most reliable source of information for the organization, is commonly assumed to be accurate, complete, and easily importable or transferable to a new application. This data almost always needs scrubbing to be accurate and complete.

b.      Integrations -  Transferring data to and from legacy systems is often time-consuming and requires careful decision-making and extensive testing. Additionally, configuring and integrating a new application uncovers variations in business rules across the organization. As a result, project progress may encounter significant delays or come to a halt while the business strives to clarify and resolve these inconsistencies.  

2.      Project Scope - The circle in the middle lists the very high-level features and functions the business expects from the new software application.

3.      Outputs – A list of what information we want from the new application. It can be reporting or an interface to push data to another legacy system, like accounts receivable or finance. Frequently the list of outputs triggers discussion to determine which specific system is responsible for performing calculations on data and what methods need to be employed. 

When I think a project sponsor will want to jump right into a project, focusing only on the new software, I add a few other comments on the 8X11 sheet to keep risks and a possible solution top of mind. In the sample above I included reminders of risks and suggested phases of work to address those risks. Every project’s needs are different, but the point is to keep these reminders visible, succinct, and only include information that might impact the schedule and budget.

If the decision is made to jump right into a project and start configuring our new application, as project managers, we point out the risks, suggest mitigation, and then get to work getting the project started.  If overlooked components of work are ignored up front, stay aware that a secondary risk beyond impact to the budget and schedule is the project team morale. When the barrier arises due to poor planning, the team typically experiences stress and frustration from continued pressure to meet the originally committed timelines. This pressure can also lead to stopgap or throwaway work which either stays in an imperfect state, affecting the satisfaction of the application’s users, or must be reworked later.  

The context diagram represents our big view of the project. It stays visible throughout the project work to stakeholders, the project team, the project sponsor, and executives. When we reach barriers to meeting the expected schedule and budget, the diagram makes it easy to explain the required changes and negotiate for additional time and budget.

In conclusion, understanding the entire scope of work in a technology project is essential to avoid overlooking critical components that can impede progress. While configuring software applications like Salesforce may seem quick and easy, there are numerous variables to consider beyond mere configuration. The ever-useful context diagram serves as a visual representation of inputs, project scope, and outputs, not only highlighting hidden work effort and potential risks, but also proves useful in communicating changes and negotiating adjustments when barriers arise. 

Contact me to continue the conversation. 

#SoftwareProjects #ProjectManagement #TechnologyProjects #ProjectPlanning #ContextDiagram #RiskMitigation #LegacySystems #DataIntegration #ProjectScope #ProjectProgress #BusinessProcesses #ITManagement #BusinessStrategy #ProjectLeadership #TechProjectTips