When I speak with my colleagues about problem solving and structured thinking, I find that a common theme has been the “systems development life cycle,” as it has been incredibly useful tool for me in these very situations.
As I have these conversations, it’s become clear that I truly am an incredibly process oriented individual and I find great value in structured thinking and structured problem solving, especially when it involves a system of sorts. I believe that this type of thinking can lead to innovative solutions, and more times than not, it will ensure positive results.
I believe that this also pertains to another area that I have been talking about with my team, driving results. How do you motivate a group of individuals to come together to accomplish a task that may seem insurmountable to some?
I believe it happens through structured thinking, through small steps and positive feedback loops which help to ensure success over time–sustainable competitive advantage–if you will.
Lately, I have also been thinking a great deal about my style of leadership and how I generate results, how I motivate, and what my problem solving process looks like. With all of these conversations happening at once, I came to a rather obvious conclusion: most things can be treated as a system that needs refinement.
Everything is a system.
What I mean when I say “everything is a system” is really that most situations one encounters within the business world can be classified as a series of smaller units working together to achieve a greater result.
Therefore, when dealing with a goal or task, you can almost always break said goal down into smaller, more manageable parts, and deal with each of those parts separately and jointly to solve the problem at hand. Sounds rational and a bit like common sense, no?
I find myself doing this daily during typical problem solving.
When needing to maintain strong performance in specific business metrics (which area is almost always complex) it is important to be process oriented and follow a structured methodology to achieve results.
Systems Development Life Cycle
The systems development life cycle (SDLC) is a process of creating or altering systems and refers to the models or methodologies that people use to develop those systems.
It is typically a project management technique that divides complex projects into smaller, more easily managed phases. Segmenting projects allows managers to verify the successful completion of project phases before moving forward with subsequent phases. It typically follows a logical process order, which involves the requirements stage, design stage, implementation stage, verification (testing) stage, and maintenance stage.
This is a very specific methodology to solving complex systems issues–and depending on the scope of the project–there are two main types of methodologies that one might utilize: the Waterfall method, or the newer, quicker, Agile method. There is endless debate as to which is the “proper” method to follow, but in order to continue the discussion, it is important to provide a brief background on each.
Waterfall (tried and true!)
The Waterfall method is such that one follows a linear and strict set of stages during the entire development process, and one is unable to revisit any previous stage without restarting from the beginning. Because of this format, it is considered on of the best methods for extremely large and detailed systems.
It follows seven unique stages: identification and selection, initiation and planning, analysis, requirements, design, implementation, and maintenance.
This process brings discipline, rigor, and order to the problem solving and development process of these complex systems, while facilitating a knowledge transfer at each stage. This enables the ability to verify the success of each stage. Using the waterfall method will often times result in high quality systems that exceeds client (internal/external) expectations, reaches completion within time and cost limits, and is efficient and effective.
The method moves forward through the stages from top to bottom just like a waterfall, hence the name. This does not mean that the phases may not overlap, but ideally, there will be no backward movement in the life cycle.
However, some critics argue that such a specific and forward moving process means that “glitches” or problems that arise early-on can exponentially grow in cost as the project develops. For example, a $10 glitch in the analysis phase, can reach $1M+ by the implementation stage, and moving backwards to fix such a problem is practically an impossibility due to the complexity of the system.
Other critics argue that clients may not be aware of exactly which requirements they need, and only by reviewing a working prototype and commenting on it will they become apparent. Frequently, clients may change their requirements, and the Waterfall methodology does not permit this type of ambiguity. For this reason, ensuring accurate analysis and requirements collection is of the utmost importance, which requires extreme diligence and rigor by the business analyst group working on the project.
Agile (quick!)
With the critics of Waterfall touting the seemingly unnecessary level of risk involved, Agile comes into play.
It is a “low over-head method” that “emphasizes values and principles rather than processes.” Working in cycles i.e. a week, a month, a quarter, etc., project priorities are re-evaluated at the end of each cycle and changes are made to ensure stages meet requirements. The system is in constant testing with this method, and it allows for quick course correction and level setting throughout the entire system development life cycle. (Major Benefit!)
The Agile Introduction site specifies the four principles that constitute Agile methods as:
- The reigning supreme of individuals and interactions over processes and tools.
- As does, working software over comprehensive documentation.
- Likewise, customer collaboration over contract negotiation.
- And again, responding to change over plan follow-throughs.
“To synopsize the difference between the two, one can say the classic Waterfall method stands for predictability, while Agile methodology spells adaptability. Agile methods are good at reducing overheads, such as, rationale, justification, documentation and meetings, keeping them as low as is possible.” And, that is why Agile benefits small teams with constantly changing requirements, rather more than larger more complex projects like ERP.
The Agile Introduction site continues with “Agile, based on empirical rather than defined methods (Waterfall) is all about light maneuverability and sufficiency for facilitating future development. By defined methods what one means is that one plans first and then enforces these plans. However, Agile methods involve planning what one wants and then adapting these plans to the results.”
Waterfall vs. Agile
Waterfall’s well-defined stages allow for thorough planning, rigor in process (especially for logical design, implementation and deployment) and work best with incredibly large and complex systems. Think ERP, server farms, building or construction projects.
Agile methodology is a sound choice for small projects, certain software development projects (quick to market), or web-based design; and with the proper mindset, firms can successfully implement Agile solutions. It’s still not great for systems that don’t allow for backwards movement.
But–in all of the conversations I’ve been having with various consultants and business analysts–they tend to say that waterfall is the methodology of choice for the larger complex systems that are being developed and deployed by their firms today.
A Hybrid Methodology for Business Problem Solving
Then, there’s a hybrid methodology, which is a system that is not as rigid as the Waterfall method, and not nearly as malleable as in Agile. I find it describes my daily problem solving system.
As a manager, it is my job to motivate individuals, inspire team members to achieve our group goals, and be accountable to the results of the business. It is also helpful when one needs to be focused on increasingly larger goals as set by my corporate leadership and to ensure my team’s adoption of those goals.
Waterfall is too rigorous for my current needs, and Agile has it’s limitations (pdf), but when it comes right down to it, I incorporate many of the processes of both methodologies into my daily routine. As such, I believe it is imperative to follow the “standard” stages when moving through a problem solving life cycle as in the systems development life cycle; BUT–in certain situations–it is also important to revisit and revise these stages periodically to verify success. If these stages have not been successful, then it is time to realign the current action plan and revisit previous stages.
- Determine goals! - write them down
- Determine the requirements for assessing the system - write them down
- Assess the state of the system against the requirements - logical and methodical
- Design a plan to attack the problem.
- Implement plan (Build and change behaviors)
- Test plan
- Analyze plan - objectivity and logic win!
- Adjust or maintain progress depending on analysis
- Implementation
- Adjust or maintain progress
How I use this daily methodology with people / technology
For example, let’s say you are asked to achieve sales goals of 10% over prior year during a recession for a key product for your firm… This may seem insurmountable to some, but I believe that with the proper problem solving skills, you can achieve your desired results.
And it starts by asking the right questions (goal setting, requirements gathering, and assessing)! By being dedicated to the process, writing down the criteria, breaking the goal into smaller pieces that can be positively impacted, implementing change, and readjusting and realigning to ensure the goal is being met, you will be able to ultimately add up the results and exceed the goal.
Most importantly, if something isn’t working or has changed, go back and revisit prior stages. Which is why I call this a hybrid approach, as it varies from the standard IT version of the SDLC. A true waterfall method would allow zero backward movement, and true Agile is not nearly as strict. I imagine most people do this in some way or another, but to be truly successful with this approach, one must follow the process (write the goals/requirements/assessments down!) and be objective when determining when to realign.
It is also important to note with being process oriented, one must also be able to adequately deal with ambiguity and challenges as they arise. Too many times, can one become paralyzed with inaction due to the “thinking” involved in the systems approach, so keep the pace.
Conclusion
Problem Solving is a Process! Structured thinking helps you look at problems in a rigorous and methodical way, which brings logic and organization to a problem with which natural thinking most certainly does not. It helps with analysis and implementation of solutions for business problems (and other problem solving situations) and can ensure that you have a good starting point where others would feel intimidated.
MindTools has a great introduction to other structured problem solving techniques.
{ Comments on this entry are closed }
