Alt+Ctrl+Start

I’ve worked with a fair few software developers and engineers in my time in the IT workforce. Most of them are kind, willing to share their knowledge and talk about their work. No problem here. Most of them are hard working and very knowledgeable on their choice of language.

However, near the end of some major projects I’ve experienced, I tend to question some of the final workings and functions of the project. For example, if a Content Management System (CMS) / website was meant to perform function ‘A’, but ‘A’ did not execute as intended; what would happen in this situation; or if ‘A’ did not happen but scenario ‘B’ happened, what would happen in this situation? (Check out my “what would you do in this scenario” post https://infotechmentor.com/2024/11/24/what-would-you-do-in-this-scenario-build-and-learn-on-your-troubleshooting-skills-coming-soon/) When I ask these questions, things tend to go quiet (cricket sound). I guess what I’m trying to say here is, during the course of the project, have all scenarios been defined? In most cases it’s a resounding no.

In situations like this I’ve seen developers and engineers cop a bit of hiding from snr management and others around the workforce, for not picking these scenario’s up earlier. This doesn’t happen all the time, but I’ve seen it occur. No one or team deserves blame. However these situations always pop up each time I’m asked to look after the final phases of the project and from experience for some reasons the developers are the first to get a mention.

For these situations to be addressed, projects really need to define their scenario’s at the very start. A deep thought on “what might happen, if such and such happens, if X is not performed/executed properly” etc, needs to really happen at the start of any project. Unfortunately most people executing projects will never have this deep thinking (but if you want to improve and add an extra 10% to your learning check out my 10% rule post, https://infotechmentor.com/2024/10/23/the-10-rule/). When designing a solution one needs to think about all, if not most of the worst case scenario’s. Why? Because it will happen. Once a solution is almost complete there’s is almost no way to building the extra functionality needed to address your “what might happen” scenario’s.

Below are some tips which can be applied, during the Analysis and particularly the Design phases of the project, to identify the “what if” scenario’s earlier.

• Firstly understand and map out what the solution is meant to do
  • Has anyone provided a visual map, diagram, image on what the solution is meant to do, perform, execute etc?
    • You can’t possibly begin to identify the “what if” scenario’s if there is no visualisation on the solution.
  • If not make sure someone in the project can provide an end to end representation of the solution.
  • The visual should contain all elements of the solution. E.g. Customers, Server names, network links, 3rd party systems, vendor systems, along with some documented purpose of these elements.
• Ask where the entry / start of the solution begins
  • You want to know where the start of the journey into the solution begins
    • This is important because this is the first step in identifying the first few “what if” scenario’s
  • Once you’ve identified the start (E.g. The login button into the CMS) begin by asking, “What happens if the customer can’t login; what if the login fails? Does the customer have a way to reset the password, request a new password, do they need to call a help desk?”
    • This example above demonstrates the first “what if” scenario. Scenario ‘A’ where a customer is trying to log in, is instead presented with Scenario ‘B’ where the customer can’t login.
    • For this example, someone should confirm the the login feature has some form of password reset functionality.
      • If it doesn’t exist make sure someone in the project document’s this particular case.
      • (As mentioned the above is just an example. But should form an idea on how to approach these situations).
  • After you have identified the start of the solution, you can then begin applying the same thinking to other functions of the solution
    • Tip – obtain the top 5 functions the solution is meant to perform. You can then scope out some “what if” scenario’s for these functions
• What happens If Scenario ‘B’ occurs instead of Scenario ‘A’?
  • For this question, you will get an ‘I don’t know’ response or cricket sound.
  • Ask if there is a work around, another function, or temporary solution to address Scenario ‘B’
  • Is Scenario ‘B’ acceptable, intended or reflects a broken process in the solution?
    • If the scenario is not intended and represents a broken process will it get fixed, during of after the project is delivered?
  • For this example, we’ll use the login function for the CMS in the previous point.
    • Let’s say the user has managed to reset the password through an email prompt. But the email prompt is no where to be found. The user has checked their inbox and spam folders, but the email prompt is no where.
    • What would the user in this case do?
      • How does the user troubleshoot this issue?
• You can go even further and ask, is there a Scenario ‘C’, ‘D’, (‘E’)?
  • If you think about a scenario, don’t be afraid to hide it
    • Maybe a good approach would be to first assess the entire solution, write down your scenario’s and then raise it with the project manager.
      • As a side note, just be prepared on some push back. Some project managers are just looking to push project’s along, deliver it at a certain time and only worry about these “what if” scenario’s later.
      • Later usually mean’s no more money or time on the project after it concludes.
• Document the “what if” scenario’s and address these during the course of the next phases of the project cycle
  • After identifying the various “what if” scenarios the project might not have the time or budget to provide fixes
  • Make sure they are captured somewhere as a reference
  • During the course of the project these “what if” scenario’s might get picked up at a later stage

Summary

• The purpose of this post is to identify some possible scenario’s that will happen after the project is delivered.
• Everyone needs to take some responsibility during the SDLC to question aspects of the project
  • In the end we are building solutions to serve customers. There will be functions that break, not behave as intended etc, and should be questioned along the way of the project
• Build this skill over time, little questions here and there tend to be the most important
  • After reviewing the solution at the analysis and design phases, have a deep thought and ask yourself the possible weaknesses in the flow of the solution
• You might not be able to pick up on every “what if” scenario but it at least it will be a good start, rather thinking about it after the project has concluded.