Closing the Loop    

Understanding the IT requirements of your clients’ business, is one of the most important, and underrated, abilities of an IT consultant. To be successful, IT knowledge must be applied with a clear understanding of how it needs to function for the client. Even armed with an understanding of software, hardware, networking, end user behaviors, and being prepared with extensive technical knowledge, you may still have bad IT. So, removing the gaps in your IT or what I call ‘Closing the Loop’ is one step to moving beyond the simple title of ‘geek’ and becoming a true IT professional.

Everything in IT is ultimately driven by business goals. If the business leaders involved haven’t set or specified your goal, you have a playground - enjoy it while you can. Having a business goal is the starting point for closing the loop. At the end of the project, you will ask whether you achieved the business goal. And, if so, how do you know?

Most IT projects involve deployment of a service, such as a website, email, or improved network connectivity, to meet a business goal, such as marketing a product, enabling customer communication, or providing better internet access for staff. The functionality of this service is your next marker point, forming a check list for success. Before claiming the project has been successfully completed, check that these services are up and available, and whether they come back online after the device is restarted. While sometimes it isn’t possible to restart the server, you can set the service to start when the server powers up again. Your check list: is the primary service available, does it work, and if so, how do you know?

To establish functionality of a service, often secondary services are required. For example, the status of remote connectivity is your third marker for success. When contemplating the project, required secondary services should be listed to ensure that nothing is missed. Then you can check: Do these services come back online after the device is restarted? As with the primary service, are they available, do they work, and if so, how do you know?

Finally, we have the end users. Did they get what they needed, and if so, how do you know?

How do you know? So far I have been asking “How do you know?”. How do you know? You test. Testing should be performed throughout the process. At the end of the project you should test again to ensure completeness. The list of primary and secondary services comes in handy at this point. Tests only need to be as complicated as the services which they provide; for instance, testing an email server is pretty simple compared to testing a disaster recovery plan.

I mentioned remote connectivity as an example of a secondary service. Always test remote connectivity before final implementation, otherwise you may end up having to make a trip to the device location whenever an emergency occurs. This will extend the necessary service repair time.

Planning your tests Let’s return to the business goal, the services, and the end users. To ensure your services are working as required, test for expected results. Keep one thing in mind when testing, while many servers and devices appear to be radically different, when testing, they are remarkably similar.

A simple test template can, and should, be drawn up and reused with only minor tweaks.

The test template should have the following items at minimum.
  - TCP/IP addressing
  - Routing
  - DNS (Local)

Y   N
Y   N
Y   N
- Reachable
  - Remote access
  - DNS (Network Internal)
  - DNS (Network External)

Y   N
Y   N
Y   N
- Services
  - Primary service _______________
  - Secondary Service #1__________
  - Secondary Service #2__________
  - Secondary Service #3__________
  - Secondary Service #4__________

Y   N
Y   N
Y   N
Y   N
Y   N
- Documentation
  - Updated

Y   N

Use this to start from, and add test requirements as needed. Just as no two organizations are the same, no two projects are the same, and so no two test templates will be the same. Customize the test templates to meet the primary and secondary service requirements.

Many of these tasks do become habitual. Though I caution against relying on habit alone as specific or unique tasks can be forgotten.

Closing the Loop
Selling a closed loop process to upper management often may be difficult as it adds time and money to every project. In many cases management’s attitude is to see the project completed ASAP and then move on to the next one. This line of thinking often isn’t in their best interests. Projects scheduled to follow are pushed back when there is a problem with the earlier project which needs your attention, also end users are impacted when the services they expect are not available as expected or worst yet, are denied. Upper management may have difficulty in enforcing the closed loop process as their IT staff’s ego may come into play. Knowing that everything works, not just accepting that everything should work is important to management, and should be of primary importance to all IT professionals; both in house and outsourced alike.

Originally published September, 2008
Fragment - Current Release


IT Roles and Responsibilities
On Passwords
Spending Enough
Planning to Fail
Living With the Enemy
A Reason for Policy
Mission Critical Messaging – Do you have a policy
Globalizing the SMB
High Availability: People and Processes
Case for Project Management
Risk Management

On Routing
VLAN Tutorial
IPs 4 Golden Rules
WAN Technology primer
DHCP Primer
Your Head in the Cloud(s)
DNS: Terms and Process
VPN Surfing Challenge
Network Slowdown
Importance of Time
High Availability: Technologies

Spammers Go Full Circle
Beyond the Lock
The Guardian at the Gate
A Web of Trust
Data Breach Notification

Electricity Primer
Data Control
Open Source in the Enterprise
Closing the Loop
Helping IT to help you
Your ICT Keystone

eSubnet Services

Contact us regarding your network,
security and Internet services needs

All content © eSubnet 2003-2021