Best Practices for System Analysis – A Decade and a Half of Consistent Learning
Best Practices for System Analysis – A Decade and a Half of Consistent Learning
In the realm of system analysis, most professionals know that projects most often run over budget and over the allotted time for completion. This is a wide-spread problem that although known, is still causing major issues in system analysis and design. In my years of experience in business consulting and in developing software, I have noticed that the issues are due to differing circumstances ranging from situations that can be anticipated and controlled to situations that are unimaginable at first (these creep up when it’s too late to turn back!!!).
This knowledge has been accumulated through failure, sweat and tears, and triumph in a multitude of projects spanning a 15 year business that I opened up straight out of high school. If there was a mistake to be made, I can assure you that I made it. I would not change a single experience as every failure provided a necessary bit of knowledge that is now part of the Inventek ™ methodology used for software analysis and design. This methodology is based off of best practices, industry practices, and knowledge gained.
Many successful software designers use similar approaches. The issue with the standard approaches seen in text books is that every business is different and every organization has a set of intricacies that require certain flexibility. For us, our developed methodology works. As long as you end up understanding the best practices and knowledge base from this or any methodology, you will be able to adapt and develop your own successful best practices that will hopefully save you from some failures. Do note that failure is never really failure, but an opportunity to learn and develop experience.
As part of the software development world, my business has had a fair share of projects that have gone over budget and have gone over the scheduled timeframe. What I want to do is go over a few of these failed projects and provide some insight as to mistakes and the knowledge gained from these experiences. There is no way to go over every single one. However, these will highlight the big system killers.
Inventek ™ Warehouse – Lesson: It’s not about Understanding…it’s about learning HOW to Understand
The first commercial project that I took up was the development of an inventory control system for a warehouse that was approximately about 50,000 square feet. My first real mistake was thinking that it was easy and I thought I understood inventory well enough to control it. However, I was nineteen at the time and being young provides a level of innocence that quickly makes one look naïve. It also provides you with opportunity, and I was not about to let a lack of experience get in the way of my first commercial application (and making some cold hard cash!!!).
Completing this project ended up being much much much harder than I expected. Mainly, I did not know enough about the business to model it correctly. For example, I did not know about LIFO or FIFO (last in first out and first in first out) inventory models. I did not know about inventory credits or how to handle returns. I did not know how this had an impact on returns, among many other scenarios.
What I learned from this experience was that you have to ask a lot of questions. Initially, you just ask questions. Eventually, you learn how to ask the right questions (this is with experience though). We currently have a list (divided by industry type) of the most common questions based on the typical issues faced by the style of industry. We also collect their paper trail, which helps develop follow up questions. What I mean by paper trail is to ask for any document that someone fills out when processing anything. This can be anywhere from a merchandise reception form to a return credit authorization. Essentially, everything and anything that a human being fills out at any point. This starts painting a process, which you then use to draw a model of how their business process works. This is the centerpiece to understanding ANY business. If the business process is properly modeled, then you now understand how the business operates. You have to combine the paper trail with your observations of the business. How do they do things? Who is in charge of what? What is filled out? Why? Once you know how the business operates, you can optimize it and systemize it. Without this, what you have are a sequence of migraines that will hit you one after another. Not to mention, crappy software based on assumptions.
Inventek ™ RX- Lesson: Scope Creep will kill a Business
Learn how to say NO. Repeat after me: LEARN HOW TO SAY NO. Repeat: LEARN HOW TO SAY NO! Got it? I wish someone would have made me learn this!!!!
Someone who had purchased my point of sale software (Inventek ™ POS, our most widely successful product with a user base of over 10,000), asked me to develop a pharmacy application for them. Given that this was our biggest customer (he owned a huge multinational chain) I was reluctant to say no. Even though I should have known better from about 5 years of experience at this point (I was about 24 at that time), scope creep killed me. Scope Creep basically happens when the user or designer continue to add requirements to the software with no end in sight. This happens for multiple reasons, including: a lack of foresight, a user that keeps thinking of new ideas, an inability to say no to changes, etc.
I just did not have the guts to say no to this customer. Therefore, every time he had a new idea (while the project is still being tested and developed), he would add it to the list of requirements. This was a cycle that was very hard (and expensive) to break. The scope just kept growing and growing while the price of the project had already been negotiated and was fixed.
In the long run, trying to keep one customer happy nearly drowned me and my team in work. I had to end up stopping the customer and ended up doing what I should have done in the first place: give him a piece of paper to sign with a list of negotiated requirements and a price per hour should anything be added to that list. This way, scope creep is kept in check, or we get a check!
Our Version of Windows Vista – Lesson: What you think is Cool and what the End-User Thinks is cool MUST Align!
It’s always fun to laugh at software debacles unless they become your own. Windows Vista was probably the worst operating system ever designed by Microsoft. Primarily, Microsoft created a bunch of features that Microsoft thought were neat and necessary and end-users saw as annoying and stupid. Well, Inventek ™ Point of Sale 5.0 suffered from the same issues. At this point, we had grown a bit and wanted to release a new version that would be much more sophisticated and would have a lot of really cool features. This project was headed by one of the best developers that I ever had the pleasure of working with and I had no doubts as to his development skills. The team came up with the features, developed these features, and released the update….drumroll please……FLOP!
Wow what a colossal failure. Not only did end users absolutely hate it, but they were reverting to older versions of the software. Where did we go wrong? Well wow, were do I start?
One of the advantages that I have gained as an entrepreneur and software developer is to think about the solution from the perspective of the business and not the software developer. I think and see a problem how a business person thinks and sees a problem and not how a developer would. This has led to a lot of successful software as business users love the experience of the Graphical User Interface and its simplicity. It does what it is supposed to do in a way that a business user can understand without having a PhD in Software Engineering….except this was not the case in Inventek POS 5.0. We went away from our core as I gave control of this aspect to a developer (a very skilled one). Ultimately, it was my failure as you should never ever outsource your core competencies. I stepped aside without guiding and without providing consistent feedback. I got complacent and I failed miserably.
This, however, was a short-lived failure as it turned out to be the best team building experiences. I never blamed anyone but myself for this event and I did not run away from it either. When I took responsibility for the failure, my team rallied as they understood that I would never punish innovative thinking regardless of the outcome. This allowed us to enter a very creative phase and produced ideas that are still being built today. Ultimately, we learned that including customers in the development of features is an important step. This DOES NOT mean that you only develop what customers ask for. This is not the case as customers do not always know what they want.
While there are many other projects that produced best practices, these three are the most fundamental as they are where many analysts go wrong. Never believe or listen to someone that tells you that there is a bullet proof methodology or that their way is guaranteed to work. Allow yourself ample room to work with, learn, adapt, and reflect. That is the true methodology. Most importantly, never be afraid to fail. Experience is what you obtain when you do not obtain the results that you initially intended to achieve.