Quite often I am faced with talking to people about their system designs, plans and architectures. \u00a0And many times that discussion happens too late and designs are either already implemented or they are partially implemented. \u00a0This can be very frustrating if the design in progress has been deemed to not be ideal for the situation.<\/p>\n
I understand the feeling of frustration that will come from a situation like this but it is something that we in IT must face on a very regular basis and managing this reaction constructively is a key IT skill. \u00a0We must become masters of this situation both technically as well as emotionally. \u00a0We should not be crippled by it, it is a natural situation that every IT professional will experience on a regular basis. \u00a0It should not be discouraging or crippling but it is very understandable that it can feel that way.<\/p>\n
One key reason that we experience this so often is because IT is a massive field with a great number of variables to be considered in every situation. \u00a0It is also a highly creative field where there can be numerous, viable approaches to any given problem. \u00a0That there is even a single “best” option is rarely true. \u00a0Normally there any many competitive options. \u00a0Sometimes these are very closely related, sometimes these options are drastically different making them very difficult to compare meaningfully.<\/p>\n
Another key reason is that factors change. \u00a0This could be that new techniques or information come to light, new products are released, products are updated, prices change or business needs change near to or even during the decision making and design processes. \u00a0This rate of change is not something that we, as IT professionals, can hope to ever control. \u00a0It is something that we must accept and deal with as best as we can.<\/p>\n
Another thing that I often see missed is that a solution that was ideal when made may not be ideal if the same decision was being made today. \u00a0This does not, in any way, constitute a deficiency in the original design yet I have seen many people react to it as if it did. \u00a0The most common scenario that I run into where I see people exhibit this behaviour is in the aversion to the use of RAID 5 in modern storage design, RAID 6 and RAID 10 being the popular alternatives for good reason. \u00a0But this RAID 5 aversion, common since about 2009, did not exist always and from the middle of the 1990s until nearly the end of the 2000s RAID 5 was not only viable, it was very commonly the best solution for the given business and technical needs (the increase in aversion to it was mostly gradual, not sudden.) \u00a0However many people see RAID 5 as understandably poor as an option today but apply this new aversion to systems designed and implemented long ago, sometimes close to two decades ago. \u00a0This makes no sense and is purely an emotional reaction. \u00a0RAID 5 being the best choice for a scenario in 2002 in no way implies that it will still be the best choice in 2015. \u00a0But likewise, RAID 5 being a poor choice in 2015 for a scenario in no way belittles or negates the fact that it was very often a great choice several years ago.<\/p>\n
I have been asked many times what to do once less than ideal design decisions have been made. \u00a0“What do I do now?”<\/p>\n
Learning what to do when perfection is no longer an option (as if it ever really was, all IT is about compromises) is a very important skill. \u00a0The first things that we must tackle are the emotional problems as these will undermine everything else. \u00a0We must do our best to step back, accept the situation and act rationally. \u00a0The last thing that we want to do is take a non-ideal situation and make things worse by attempting to reverse justify bad decisions or panicking.<\/p>\n
Accepting that no design is perfect, that there is no way to always get things completely right and that dealing with this is just part of working IT is the first step. \u00a0Step back, breathe deep. \u00a0It isn’t that bad. \u00a0This is not a unique situation. \u00a0Every IT pro doing design goes through this all of the time. \u00a0You should try your best to make the best decisions possible but you must also accept that that can rarely be done – no one has access to enough resources to really be able to do that. \u00a0We work with what we have. \u00a0So here we are. \u00a0What’s next?<\/p>\n
Next is to assess the situation. \u00a0Where are we now? \u00a0In many cases the implementation is done and there is nothing more to do. \u00a0The situation is not ideal, but is it bad? \u00a0Very often the biggest mistake that I see people facing of an all ready implemented design is that it is too costly – typically “better” solutions are not better because they are faster or more reliable but are better because they are cheaper, easier or faster to have implemented. \u00a0That’s an unfortunate situation but hardly a crippling one. \u00a0Whatever time or money was spent must have been an acceptable amount at the time and must have been approved. \u00a0The best that we can do, right now, is learn from the decision process and attempt to avoid the overspending in the future. \u00a0It does not mean that the existing solution will not work or even not work amazingly well. \u00a0It is simply that it may not have been a perfect choice given the business needs, primarily financial, involved.<\/p>\n
There are situations where a design that has been implemented does not adequately meet the stated business requirements. \u00a0This is thankfully less common, in my experience, as it is a much more difficult situation. \u00a0In this case we need to make some modifications in order to fulfill our business needs. \u00a0This may prove to be expensive or complex. \u00a0But things may not be as bad as what they seem. \u00a0Often reactions to this are misleading and the situation can often be salvaged.<\/p>\n
The first step once we are in a position where we have implemented a solution that fails to meet business needs is to reassess the business needs. \u00a0This is not to imply that we should fudge the needs to massage them into being whatever our system is able to fulfill, not at all. \u00a0But it is a good time to go back and see if the originally stated needs are truly valid or if they were simply not vetted well enough or, even more likely, to go and see if the business needs have changed during the time that the implementation took place. \u00a0It may be that the implemented solution does, in fact, meet actual business needs even if they were originally misstated or because the needs have changed over time. \u00a0 Or it might be that business needs have changed so dramatically that even perfect planning would originally have fallen short of the existing needs and the fact that the implemented solution does not perform as expected is of minor consequence. \u00a0 I have been very surprised just how often this verification of business needs has turned a solution believed to be inadequate into an “overkill” solution that actually cost more than necessary simply because no one pushed back on overstatements of business needs or no one questioned financial value to certain technology investments.<\/p>\n
The second step is to create a new technology baseline. \u00a0This is a very important step to assist in preventing IT from falling into the drop of the\u00a0sunk cost fallacy.<\/em>\u00a0 It is extremely common for anyone, this is not unique to IT in any way, to look at the time and money spent on a project and assume that continuing down the original path, no matter how foolish it is, is the way to go because so many resources have been expended on that path already. \u00a0But this makes no sense, of course,\u00a0how<\/em> you got to your current state is irrelevant. \u00a0What is relevant is assessing the current needs of the department and company and taking stock of the currently available solutions, technologies and resources. \u00a0Given the current state, the best course forward can be determined. \u00a0Any consideration given to the effort expended to get to the current state is only misleading.<\/p>\n A good example of the sunk cost fallacy is in the game of chess. \u00a0With each move it is important to assess all available moves, risks and strategies again because what moves were used to get to the current state have no bearing on what moves make sense going forward. \u00a0If the world’s greatest chess player or an amazing computer chess algorithm was to be brought in mid-game they would not require any knowledge as to how the current state had come to be\u00a0– they would simply assess the current state and create a strategy based upon it.<\/p>\n This is the same as we should be behaving in IT. \u00a0Our current state is our current state. \u00a0It does not matter for strategic planning what unfolded to get us into that state. \u00a0We only care about those decisions and costs when doing a post mortem process in order to determine where decision making may have failed in order to learn from it. \u00a0Learning about ourselves and our processes is very important. \u00a0But that is a very different task from doing strategic planning for the current initiative.<\/p>\n The unfortunate thing here is that we must begin our planning processes again but this time with, we assume, more to work with. \u00a0 \u00a0But this cannot be avoided. \u00a0In the worst cases, budgets are no longer available and there are no resources to fix the flawed design and achieve the necessary business goals. \u00a0Compromises sometimes are necessary. \u00a0Making do with what we have is sometimes that best that we can do. But, in the vast majority of cases it would seem, some combination of additional budget or creative reuse of existing products can be adequate to remedy the situation.<\/p>\n Once we have reached a state in which we have addressed our short falls, whether simply by accepting that we have over spent, under-delivered or have adjusted to meet needs we have an opportunity to go back and investigate our decision making processes. \u00a0It is by doing this that we hope to grow as individuals and, if at all possible, on an organizational level to learn from our mistakes, or determine if there even were mistakes. \u00a0Every company and every individual makes mistakes. \u00a0What separates us is the ability to learn from them and avoid those same mistakes in the future. \u00a0Growth comes primarily from experiencing pain in this way and while often unpleasant to face it is here that we have the best opportunity to create real, lasting value. \u00a0Do not push off or skip this opportunity for review whether it be a harsh, personal review that you do yourself or a formal, organizational review run by people trained to do so or something in-between. \u00a0The sooner that the decision processes are evaluated the fresher the memory will be and the sooner the course correction can take effect.<\/p>\n The final step that we can do is to begin the decision process to design a replacement for the current implementation as soon as possible, once the review of the decision process is complete. \u00a0This does not necessarily mean that we should intend to spend money or change our designs in the near future. \u00a0Not at all. \u00a0But by being extremely pro-active in design making we can attempt to avoid the problems of the past by giving ourselves additional time for planning, more time for requirements gathering and documentation, better insight into changes in requirements over time by regularly revisiting those requirements to see if they remain stable or if they are changing, more opportunity to get management and peer buy in and investment in the decision and better understanding of the problem domain so that we are better equipped to alter the intended design or know when to scrap it and start over before implementing it the next time. \u00a0It also could, potentially, give us a better chance of codifying organizational knowledge that could be passed on to a successor should you yourself not be in the position of decision making or implementation when the next cycle comes around.<\/p>\n With good, rational processes and a good understanding of the steps that need to be taken in a case of less than ideal systems design or implementation we can recover from missteps and not only, in most cases, recover from them in the short term but we can insulate the organization from the same mistakes in the future.<\/p>\n","protected":false},"excerpt":{"rendered":" Quite often I am faced with talking to people about their system designs, plans and architectures. \u00a0And many times that discussion happens too late and designs are either already implemented or they are partially implemented. \u00a0This can be very frustrating if the design in progress has been deemed to not be ideal for the situation. … Continue reading What Do I Do Now? Planning for Design Changes<\/span>