There are no shortcuts to thinking things through. There are tools and methods that can greatly help people think. I've discussed some of the ways of systems analysis that I've learned over the years to help me think, understand needs, and even listen more carefully to what people and organizations need.
I do not use most of these tools, but I do use the thinking methods I learned as I appraise a new or redesigned system.
The opportunity cost of not thinking through a system is generally not seen. We can't evaluate what we don't see.
You can "save" money by using a "build it yourself" website. It may look good. But, if you fail to understand how to fully see what your system needs, it's easy to miss an effective "Call to Action." You may not even recognize what your customers or constituents see as important.
Contact me to help you think through your next website development project, especially if you're located in Middle or West Tennessee.
Enterprise Development Before Personal Computers
In 1984, I was recruited to help define the needs of the 3,000 field offices of the Soil Conservation Service of the United States Department of Agriculture. Our computer system was a Unix system with dumb terminals. Our computer specialists at our Washington, D. C. headquarters thought they developed good requirements, but having never created such specifications, they didn't know what they didn't know. Our system was out of date before we started. Nevertheless, we attacked our software development processes using state-of-the-art methods for a dated computer hardware system.
When I was first introduced to the systems analysis tools for information technology, the emphasis was on defining processes, data flows, data stores, and external entities. 
Along with a team of peers, we spent a year creating a massive overview of the processes of our nearly 3,000 field offices. Even as we were scattered across the country with vastly different challenges and natural resources, the work our Soil Conservation offices did was remarkably similar.
As I moved into full employment with the team to build software for those offices, that overview was not sufficient. We had to construct a database, so we picked up skills in data analysis and data modeling. 
As we deployed pilot versions of the system, our agency adopted a standardized waterfall software creation model with definable steps, outcomes, and milestones. We were trying to implement a universal, policy-driven system in an organization with many different challenges. I wish that I could say that our self-imposed rigor in trying to engineer software delivered what we expected. It didn’t.
When we delivered our software to our first training classes, most of the participants had never used a computer. Seeing new possibilities within minutes of the first instructions, we had people offering suggestions and changes to how the system operated. In other words, the system was already out of date before we implemented it. Apparently, that wasn’t unusual with software development in that era. Maybe it’s still not.
The other factor that made our system outdated, was the pace of technology. No sooner than we implemented the hardware our managers believed would last for ten years, faster and much more capable computer systems became available at a lower cost. We couldn’t afford to continue buying out-of-date systems.
The Move to Personal Computers
It didn't take long to realize that personal computers, especially with the advent of the "386" chip, were the wave of the future. We looked to implement a client-server system over a local network. The Internet was basically in diapers.
By that time, we knew we and our managers had not really thought through the implementation of an information technology system. It wasn’t for lack of trying by good people; it was that trying to gain the knowledge and skills of technology that was running faster than us was impossible. Somehow we had to leap forward much faster. Those leaps had to encompass changes not only in technology but also in the management of projects, contract administration, and our equivalent to the military's materiel support.
Quite a few years ago I discovered the Capability Maturity Model (CMM) created by Carnegie Mellon University. It was a tool developed for the Defense Department to help create a more predictable, measurable framework for information technology systems. The tool contained rubrics to help an organization see which of the five levels of maturity they had achieved. It was the first time that I had seen a management strategy that differentiated ability and capability.
Along the way, I stumbled into systems thinking starting with publications by Peter Senge. 
Here Senge introduced causal effects diagrams that examine the relationships among all parts of a defined system—a very high-level view of how things work together. Having been involved in a project that created a great tool for the wrong problem, systems thinking could have averted that disaster.
At first glance, these concepts all sound like some kind of mumbo jumbo some management expert created to justify paying premium wages for consultations. What consultants know is that most people exert no more effort into thinking than they must. We’re lazy thinkers.
The CMM is for an organization. A foundation for CMM is goal setting. Yogi Berra said, “If you don’t know where you’re going, you’ll end up someplace else.” A Master Capacity Builder would help an organization create appropriate goals and the means to achieve those results.
The CMM focuses on the processes of the organization described by five factors: goals, commitment, ability, measurement, and verification. A process framework consists of five factors too: policies, standards, processes, procedures, and overview. Within those evaluations, there are multiple checklists described in rubrics—narrative descriptions of fulfillment criteria. To apply Peter Drucker’s mandate of “thinking things through,” these evaluations are a linear, forward-looking way to examine an organization.
After we created our client-server system using personal computers, two major movements changed everything.
#1. Organizational Changes and Learning to Listen
The USDA had too much duplication of effort. While the different agencies largely service the same group of farmers and others, each agency described the data differently using different computer systems. We began to reorganize to cut the redundancy and duplication through information sharing over a national network. One of my tasks was to create a customer service study composed of representatives from each of about seven agencies. Using support from sociologists from four major universities, we trained a team to use focus groups and interviews to listen to hundreds of people across the country. We called ourselves the "Listening Team." We discovered that people freely shared their suggestions.
The second part of the task was figuring out how to assess the suggestions from all of those people recorded in hundreds of pages of notes.
#2. Impact of the Internet
The Internet suddenly freed us from the constraints of old computer systems. One of my projects included the development of a content management system (before tools like WordPress, Joomla, or Drupal) to automate the delivery of web-based content--specifically the policy documents of the Natural Resources Conservation Service.
Post USDA Career
After I retired from USDA, NRCS, I started working with local non-profit organizations in my community. At one time, I was on the Board of Directors for several organizations like the Chamber of Commerce and Economic Development Groups. Meeting the needs of constituents was a growing concern for them and for several small businesses. Still learning how to transition to local systems, I ran into the concept of capacity building. The Communities of the Future movement pioneered by Rick Smyre, developed a role called “Master Capacity Builder (MCB).” People that fill that kind of community role have strategic importance in community and economic development.
Smyre introduced the notion of a futures context. Rather than try to predict future outcomes from past experiences, he suggests creating one or several contexts for the future—even futures that might seem remotely possible. After teaching Master Capacity Builders how to engage in dialog with people from a community, he advocates starting with the futures context and working backward to discover the path(s) a community would have taken to reach that place. Rather than putting emphasis on reductionist thinking through steps, stages, processes, etc., Smyre suggests that getting people into a real dialog allows them to suspend judgments and assumptions that get in the way of real problem-solving. Working backward gives a very different perspective free of biases and prejudgments. Presumably, the deep thinking of this fashion would concentrate on the capacities that a community would require in a path to some future.
Website Development As a Specialty
Shortly after I retired, content management systems like Joomla and WordPress made major headway. I prefer Joomla because of its significantly greater capacity and flexibility.
No Shortcuts
There are no shortcuts in thinking things through. There are many methods and tools that help. None are complete solutions. At some point, we have to realize that we never quite get through all the thinking required for a perfect solution, and if we did, the problem would have changed itself before we arrived with the solution. It’s not the solution that matters; it’s the hard work of thinking that matters.
To put these things into perspective, I heard the story of a young agricultural worker who told a farmer that he could help him develop a plan that would enable him to farm twice as well. The farmer quipped that he already didn’t farm half as well as he knew how. This was a clear-cut case of capability versus capacity. Most likely the farmer didn’t have the resources or inclination to work at his full capacity even if he had the ability—the knowledge and skills—to do everything required. So it goes with communities, organizations, and leaders. None perform at their full capability because capacity and ability always come up short. Thinking things through must take that into account as we constantly adapt.