This is the fifth post in a series of writings to discuss issues facing Information Technology (IT) departments. If you have not read any of the first four challenges you can find them under project work vs production support, prioritizing work, operations vs innovation, and estimating work.
IT shops vary in size, budget, and processes. But all IT shops share a common set of challenges that shape how they interact with their inter-company customer base as well as the clients of their organization. There isn’t a single answer to these common challenges and they don’t disappear after a process is put in place to address them. The manner in which IT management chooses to respond to the challenges is interwoven in the culture, processes, and services of the group. My thoughts are more around framing the problem than presenting solutions.
Challenge #5 – Understanding Project Complexity
It’s not uncommon to be in the midst of a project and to have new discovery that significantly increases the complexity of the solution. I’m not referring to intentional scope change requests. New discovery is when a detail of a scoped feature becomes known and the team has to redesign or create new alternatives and flows to existing designs. This might include a business rule for taxes, pricing discounts, or a manufacturing limitation. New discovery often leads to a scope change request document. But I classify this type of work differently because it is not a requested change in scope but more of a clarification or additional rule to an existing piece of high level scope.
Projects are usually scoped from documents such as RFPs, sales contracts, and project charters. Those are great documents, but they aren’t produced by a business analyst that has been through a series of questions to discover the finer details of project requirements. Specific use cases and functional requirements are often absent during the initiation stages of a project. In a perfect world, project teams would know every possible detail that could affect their solution set. But we don’t live in a perfect world.
The scoping phase of a project is where budgets, timelines, and tasks are defined. These three areas (triple constraint) comprise the working guidelines and constraints of the project. So if the team encounters a new discovery then it presses the working guidelines and usually requires communications with stakeholders. Where’s the fun in being over budgets or late in the deliverables?
Example 1
A new client is signed and is in the process of onboarding. While setting up the invoice process a discovery is made related to special taxing rules for orders. Depending on the customer classification they may or may not be taxed.
Example 2
During the implementation of a new customer new business rules surface about who can order product and who cannot order. The right-based system was in the original scope but the new rule set creates additional criteria to define the rights of a group or individual.
The Challenge
The challenge for a business analyst is to uncover as much of the project details before project execution begins. But the bigger challenge for project teams is how to react to new discovery and how to manage the expectations of the stakeholders. The best scenario is if new discovery does not lead to an increase in budget or an expanded timeline. But in many cases it’s not possible to finish the project without expanding the original guidelines.
I’ve framed this challenge more in terms of a traditional waterfall software development cycle. Agile methodologies also encourage some level of discovery up-front with artifacts such as user stories. But the premise of the overall challenge is the same. If we misunderstand the true complexity of a project in the early stages it can have large consequences to the work during later stages of implementation.
Next Week
Challenge #6 – Reducing Costs (SG&A)