You Can Do IT

I was reading this blog post by Gartner Analyst David Norton this morning and it got me to thinking that I’m not sure we have a good definition of technical debt to work with. I actually just had a conversation about this at a design review last week, and it was clear that we did not all have a common understanding of what technical debt means. We have a new set of mobile applications that we want to get out the door ASAP and it’s new ground for us. We haven’t done a ton of work to define best practices here, so we’re building the plane as we’re flying it. This is a good example of a situation where projects tend to accumulate technical debt.

At some point I’m hopeful that we’ll lay out a reference architecture for building web-based mobile applications. I’m actually leading the charge on defining that right now. At that point, we’ll likely have a number of applications already in the hopper and, chances are, most of them will not fit the best practices we’ve defined. Right now, we already know this is the case, but we don’t know what it would mean to pay off that debt until we have those best practices in place. Once they’re nailed down, we know what that debt looks like. We then have to decide if we’re going to pay it off. I think that’s a key point here. Technical Debit is often discussed as something that must be payed off and I don’t think that’s true.

Say you implement something before there’s an internal standard for it. It could be a new application, a new network instal, a new desktop configuration. That only formally becomes technical debt once the standard is defined. Whether we pay off that debt depends on the technical interest rate, as it were. If having this non-standard implementation in place increases support costs on an ongoing basis, it makes sense to pay off that debt sooner rather than later. For example, if all but a few of your workstations are centrally managed, you have to exert additional effort on an ongoing basis to keep them up to date. Paying off the technical debt in a timely manner will be a worthwhile practice. The challenge is the non-standard implementations that don’t have obvious ongoing expenses and obvious is an important term here.

Take the mobile application. If it’s a simple application and we’re not going to be making updates to it, that debt mostly isn’t noticeable. The place where recognizing the debt becomes important is when it comes to the risk that non-standard implementation brings. Even if we don’t make any changes to the application itself, there will be implications when it comes to infrastructure upgrades, for example. This application may require special testing above and beyond that which is required of other services. So it’s important to think carefully when considering what technical debit your services may be carrying. Consider documenting the debt as you accumulate it rather than simply accepting that accumulation. It will make it much easier to manage.

Also consider the possibility of a strategic default on your technical debt — declaring technical bankruptcy, as it were. This certainly isn’t always an option, but given the opportunity to retire a service that carries significant technical debt, one should carefully consider

• the cost of the ongoing debt to the value the service offers the organization

or

• the replacement cost of a new, debt free service.

Perhaps one of the biggest challenges of identifying technical debt is that everything has maintenance costs. In IT, there is no set-it-and-forget-it. This leaves a blurry line between an acceptable level of ongoing maintenance expense and true technical debt. As such, it would be beneficial to catalog not just known technical debit during the development phase of a new service (missing tests, non-standard implementations, missing documentation) but also potential areas of as yet undiscovered technical debt. This could be something like poor performance in the production environment.

In the end, the fist goal should be to proactive about identifying technical debt instead of waiting for it to surprise us.

I keep a copy of this cartoon posted outside my office:

It’s a reminder to myself and everyone who visits that technology is not our savior and a large portions of our problems will only be solved when we think about the root cause of a given problem. This point was driven home to me yet again while reading a great paper on UI design for multiple platforms by Gartner Analyst Ray Valdes. This quote was the one that really jumped out at me:

Although the user experience of many enterprise applications is, at best, mediocre and often user hostile, this dismal state is rarely a direct result of technology; therefor, new technologies are unlikely to fix the problems.

This gets to the heart of the problem that we, as IT Professionals, don’t focus enough on identifying the problem we’re trying to solve. If we always start with a clear definition of the problem we’re trying to solve we’re much more likely to add value to the larger organization.

I have spent a lot of time in meetings where people sit around guessing:

• How will they respond to the proposal?
• What will happen to the system under load?
• What do they want in the report?
• What does that requirement in the spec mean?

There is a lot of guessing involved in the IT profession. Some of it is valuable and some of it isn’t. What I would like to provide in just a few paragraphs is some guidance on when guessing is appropriate and when it’s a waste of time.

What’s the Question?

The first thing to consider is that when you’re guessing about something, there’s a question with an answer you don’t know. So when you find yourself stuck guessing, whether it’s by yourself or in a meeting with others, step back and figure out what the question is that needs to be answered. If there’s someone who has the ability to answer the question in a timely manner, give someone the action item to follow up with that person and move on. If it’s unclear who can answer the question or if the person with the answer isn’t readily available, focus your effort on identifying the person with authority to answer the question or how to expedite the request for an answer.

To the extent that the answer to the question at hand will have a significant impact on implementation of an IT solution and timeliness is essential, focus on the most likely answers to the question and the next steps required to address those answers. These next steps will become potential action items for individuals that can be acted on as soon as possible after the answer is defined without reconvening the group.

Who Can Answer the Question?

There are certainly times you can’t identify a person who will know a discrete answer to a question. Some common situations where this is the case include performance, system architecture and time estimating for complex tasks where pinning down an exact answer is essentially impossible. That said, even in these cases you should be able to identify someone who can help make an informed decision. For example, if you’re trying to decide on the scale of a server farm but don’t know how the servers will perform under load, you need to identify someone who can provide you with some additional information. Remember that the more information you have the better your chance of making the right decision.

In the context of project management, guessing is a risk management technique. Your guess is based on context. You’re guessing because you don’t have all the necessary data, but you do have some of it. So use the context you have to inform your guess.

When to Stop Guessing

When is guessing a waste of time? When you get hung up on it. Uncertainty breeds anxiety and often leads to uncontrolled over-thinking. The most common unproductive guessing I see is when that uncontrolled over-thinking takes the form of iterative guessing — going through the same guesses again and again rather than deciding how to get the answer to the question. When you find a meeting devolving into wild guessing, take control by bringing the conversation back to the question at hand.

To sum up: when you’re guessing it’s because you don’t have enough information to make a decision. Don’t spend any more time than necessary postulating what that missing information might be… figure out how to get your hands on it in a timely manner.

Listening is an enormously valuable and highly underrated skill in our society. It’s a challenging skill to learn, especially in our self-centered society where having your voice heard is often viewed as a key to professional and personal success. Effective listening takes discipline and patience but it’s far from a passive skill.

It’s About Context

When listening to others, remember that your comprehension of what they say is based on your own life and experience, both personal and professional. This doesn’t always put you in a good place to fully grasp what is being said. As such, it’s critical for you to grasp the context of what is being said. You must get to know the people you are taking with and where they are coming from. In personal relationships, it’s up to you to decide how much you want to invest in those relationships to understand them. But in the professional environment, you have no choice.

For example, you may work with a customer that has a particularly averse attitude to change in their IT systems. It’s reasonable that anyone would want to avoid change, but perhaps this person’s resistance is extreme with no good explanation. It would behove you understand their concerns and make sure you can address those concerns. They may not be directly related to the work you are doing, but leaving the issue unaddressed may make your work more difficult than necessary and may leave the customer with a less than optimal solution. Perhaps they had a very bad experience with change on a previous IT project. To address that, you should address those specific concerns about change rather than avoiding change all together. Understand the context and address it as an indirect dependency for your work.

Really Understanding

I find that the key to effective listening is not in hearing what they’re saying per se, but understanding what they’re saying. That means that I find myself saying “what I hear you saying is…” a lot when meeting with customers. This allows me to ensure understanding, not just hearing. I then tie my recommendations to the understandings I glean from the conversations.

Often you’ll be challenged by a situation where multiple people are saying conflicting things, or at least there appears to be a conflict. Clarifying what each person is saying and pointing out where their points of view agree and disagree is the key. This is where listening turns into facilitation. It will probably not be up to you to make decisions on the path to take when there is disagreement, but being able to point out common goals will go a long way towards helping the participants in the discussion achieve compromise.

The Value of Listening for the IT Professional

So why this discussion of listening and facilitation? Because for us to do our jobs as IT professionals effectively, we need clear specifications. Unless we can get the stakeholders to agree on what they are trying to accomplish and how they would like to see it implemented, we can’t do our work. In this context, the worst case scenario for an IT professional is to get caught in the middle of a specification dispute. If you can’t get your stakeholders to agree, you’re going to have to take sides in order to get your work done and that will likely cause political strife which can have a long-term impact on your ability to effectively conduct business. That may sound a bit heavy, but I’ve seen it happen (or nearly happen) on numerous occasions.

Listening is not a glamorous skill. By itself, it’s not going to make you a successful person. But combine it with your IT skills and you’ll find your customers more pleased and you’ll be recognized for what you are able to accomplish.

“Can’t you just add that field to the database?”

“Can’t you just write a script to update that data?”

“Can’t we just redesign the business process?”

“Can’t you just reconfigure the firewall?”

Sounds familiar? So often we have a problem that needs solving and it seems that the answer should be relatively easy. This is when “just” enters our vocabulary. The problem is that injecting the word “just” into a sentence as above usually implies that we don’t fully understand the implications of the work.

What does it mean to add another field to the database? What impact will it have on the table being changed and any related tables not to mention the data that already exists in those tables? What about other services that directly or indirectly depend on that data, including integration points or data warehouses?

How about that firewall? Just poke another hole for this IP, right? What are the security implications? Do we have policies and procedures in place for this to mitigate risk? Who needs to sign off on that change? If we haven’t made a change like this before, what is the risk of making the change incorrectly the first time? What other services are going through the firewall that might be impacted by that change?

You get the idea: there are lot’s of very real sub-questions than need to be answered and it’s rarely as easy as expected.

Now I’m not trying to suggest that we need to load every question up with tons of analysis to the point that we never get anything done. I’ve been involved in plenty of initiatives that get hung up like that. But you need to do a reasonable level of due diligence during your change management process. The fact that the word “just” enters the sentence suggests that you’re about to subvert that diligence for the sake of getting some work done.

The other issue is that the word “just” in that context can be demeaning or dismissive. If I ask a customer if they can “just redesign their business process” it suggests that I don’t value the effort it would take to do so. When I customer asks me if we can “just write a script to update that data” it devalues the real effort involved in thoroughly writing and testing that process.

So here’s my recommendation: when you or someone else inserts the word “just” into a sentence like this, it should raise a red flag. Personally, I’m trying to eliminate the use of “just” in this context. Somehow these sentences are harder to ask of people without that word and if you find that to be the case maybe you need to reconsider the question or figure out how to rephrase it in a manner that reflects the effort involved.

I previously referenced Michal Buckland’s paper Information as Thing and I would like to explore the concepts Buckland discusses therein in a little more depth in an attempt to make a bit of what I consider fundamental information theory practically applicable to the IT profession.

I was first introduced to Buckland’s paper while taking classes towards a Masters Degree in Informatics and I blogged about it at the time (as a requirement of the class). The paper is Buckland’s attempt to unify the different definitions of information, primarily: information-as-process, information-as-knowledge and information-as-thing. To complete a matrix of definitions he throws in information processing as an ancillary concept.

While many information science purists would balk at the notion of information being anything other than a process, Buckland’s paper is an attempt to address the fact that many use the term information to refer to things as information (most often the written word) or the knowledge in someone’s head. Buckland’s goal is to recognize the different definitions of information and an attempt to create a unified view of their relationships. While I found that to be a useful and information exercise, in my mind referring to things (files, models, diagrams, etc.) as information is incorrect and confusing and I would like to explain why.

After reading Buckland’s paper, I had a conversation with my very patient wife about the concepts in the paper. I talked about the concept of information-as-thing and my uncertainty about that concept. My wife, a historian, spoke up and said that I was right, that’s not information, it’s an artifact (how I love the diversity of our backgrounds!). So what we have in these things are the end result or output of the information process: information artifacts.

Why get worked up about a question of semantics and what does this have to do with the IT profession? Here’s the reason: almost every time that people refer to things (documents, data, etc) as information, they are confusing information with information technology. A spreadsheet of numbers is an IT. The numbers themselves are an IT. They are an artifact of the information process. It is confusing the information process with a storage medium for it’s output.

When working to define a technology solution to a human problem, it’s critical to not jump immediately into technology, but to look at the problem at hand. When we confuse information technologies with information as a process, it’s easy to jump into analysis of technology rather than the problem at hand. That is to say that the existing information technology may be a part of the problem. But the key is to remember that the goal of the system is information as a process.

Whether it’s informing the users of a system through a user interface or informing another system through an automated exchange of data, it’s not the information technology that is used to inform that’s critical, it’s how it supports the information process. Do you use a spreadsheet? A flat file? A web-based information dashboard? Those are implementation decisions for the presentation of data in an informative matter, they are not information in and of themselves.

Your goal should be to solve information problems with information technologies. Focus on the process you are supporting with technology and you’re less likely to be distracted by the implementing technology.

In the world of IT there is much discussion of standards-based concepts as well as best practices. I would like to take a moment to discuss these two topics and when one or the other is most appropriate in the context of the IT profession.

Standards are a rigid set of guidelines that define exactly how a task should be completed. They may provide a set of steps to be followed or requirements for coding or documentation. Generally there is not much if any room for variance, which isn’t to say that there isn’t any. Best practices, on the other hand, are a starting point from which to define practices that work in a given context. Your definition of the context and the goals of a given initiative will drive the specific practices adopted under the circumstances.

When is one more appropriate than the other?

Standards

Having strict standards is ideal when a great deal of risk is involved in the activity. For example, if you are working on a military project or a project where life is at stake you’ll probably want some strict standards, whether they’re standards for defining requirements, coding, testing or documentation. Even when lives aren’t on the line, if failure of the project or product could be catastrophic, you’ll probably want some strict standards in place.

Larger IT organizations may also need to follow strict standards for coding, configuration and deployment of software or infrastructure. If a large number of people are working on a project or if hand off from one team member to another can not be easily facilitated, standards can help keep things running smoothly. You don’t want to have to waste hours getting up to speed on the code someone handed off to you or the way a particular firewall is configured because it is done in a non-standard way. The degree to which you need to adhere to strict standards in this case is dependent on the overall size of the team and the efficiency required of the project team; i.e. bigger, more efficient teams will likely use more strict standards.

One of the more common situations where standards are appropriate, and the place you are most likely to encounter them, is in the definition of communications protocols. Without the HTTP standard, browsers and web servers couldn’t effectively communicate. Clearly this isn’t a place for best practices, although some browser implementations might make you wonder.

Best Practices

Best practices are most appropriate when standards don’t add significant value to the process and when they unduly constrain implementation.

Using best practices requires an expectation of due intelligence on the part of team members. They will regularly be asked to exercise their judgment and, when appropriate, request specific guidance. This means that there has to be sufficient trust in the team members’ judgment and that there is time to discuss interpretations of and deviations from best practices.

Best practices can also be a good gateway to standards. When you don’t fully understand the problem you’re trying to solve, it might be best to start with some best practices and solidify them into standards as you gain experience. For example, you might start with a best practice that says:

Always flip the widget when the dingle-dot is norq.

You know there will be exceptions, so there’s no point in calling this a standard. Over time, you’ll start to understand those exceptions as you apply that best practice and you may eventually end up with something like:

Always flip the widget when the dingle-dot is norq unless

• the bazoo-whop is in first position or
• the flubber-jup is out of phase

At some point you may feel comfortable codifying that as a standard.

The truth of the matter is that there is a blurry line between standards and best practices. Many things that are referred to as standards really aren’t. And even the best written standard is open to interpretation. The point of this essay is to encourage you to think about how strictly you want to enforce your standards and best practices and consider the cost of the decision in either direction.

If you are an IT professional, you are a facilitator of IT. You are almost certainly working for people who know less about the capabilities of IT than yourself. If you’re a technical business analyst, you probably know more than your client. If you’re a developer, you probably know more details of the actual IT than the business analyst or your manager. No matter where you are in the chain of responsibility, there are times that you should ask critical questions that will inform decisions about functional specifications or technical approach. Obviously if you’re on the front lines working with customers you’ll be asking more questions, but this responsibility exists at all levels. Your ability to ask these critical questions is at the heart of IT assessment.

When I was working as an independent consultant I was hired by clients on a number of occasions to facilitate relationships with other IT consultants. On one particular occasion I was helping a client work with a consultant that was helping them develop a strategic plan for IT in their organization. I questioned the consultant on the lack of detail in the training section of the plan, asking why there weren’t more specific recommendations for the kind and amount of training the organizations’ staff would require. Their response was that the organization did not indicate what training they needed. I found this response troubling. I think my jaw may have visibly dropped. The primary responsibilities of the consultant was to help the client assess their IT needs, including IT training.

When your car isn’t working, unless you know a fair bit about their inner workings, you take it to your mechanic and ask them to assess the situation and give you a recommendation. Most people don’t have the expertise to assess the situation themselves, let alone fix the problem. I may go into the shop and mention that I think I hear a squealing noise coming from the serpentine belt and I think it may be the tensioner pulley, but I certainly hope my mechanic isn’t going to just blindly replace that part without actually investigating the problem, exercising their professional expertise. Likewise, if a client asks for a specific solution to their problem, it is almost always in both of your best interests to exercise your professional expertise to define the more appropriate solution to the problem.

There are plenty of books on writing requirements, interviewing stake holders etc. but most of these take a pretty limited, step-by-step approach and handle the process pretty scientifically. But facilitating IT is an art as well as a science. So let me take a moment to make some recommendations for dealing with the less concrete aspects of this process

Focus on Information

First, make sure your process is information driven. I don’t mean the information you will gather while defining the requirements, but the information that the solution is responsible for. Remember that information is a process, not just a thing, so how does the system play a role in informing the stakeholders?

Don’t Get Caught Up in the Legacy System

You’re almost always replacing a legacy IT system even if it’s a manual, pen and paper system. While doing task analysis as part of your requirements process can yield useful information, it can also impede your ability to think about what’s possible with modern ITs. Better to maintain your focus on the goals you are trying to achieve and think about the ideal process flows rather than those dictated by the existing system.

It’s About People

Information is about keeping people informed. So when you are thinking about the outputs of your system, whether you’re talking about user experience (UX) or reports, remember that the main goal of your system is to inform its users. There are lots of best practices for user centered design in the UX domain, but little of the literature is information focused. Remember that the goal of your UI and reporting system is to ensure that the system’s users are effectively provided with the information they need.

Don’t Spend a Lot of Time Guessing

Despite the fact that there is a lot of work involved in gathering requirements, it seems that a great deal of time is spent guessing what the client needs. Stop it. Just stop. Focus on the important questions. If you come up with a question when the client isn’t present, jot it down and move on. If the question will hold up your ability to move forward, find a way to get in touch with the client and get the question answered. Chances are, though, that there’s something else you can focus on until a scheduled meeting or a convenient time to discuss the matter. The only time you should spend on questions you don’t know the answer to is in formulating a good way to ask the question.

Therein lies the one of the real keys to effective facilitation of IT: asking good questions. The four suggestions above are just a few ways to focus your questions.

Working in IT almost always implies being seperated from the mission of the organization. Unless you work for a company whose sole business is IT, the day to day business of your organization or clients is almost always at least one step removed from the work you do. For example, I work in higher education. I help build software that supports the education and research mission of the university, but many of the systems we support are already at least one step removed from that mission. So I support an application for our HR department, which supports employees that perform the research and education work on campus.

How do we make sure the work we do support the mission of our organization?

I’m generally a fan of (well written) mission statements and some smart folks in my department put together a pretty good one for us a few years back that I would like to share:

Administrative Computing Services provides high-quality, innovative and comprehensive Information Technology Services, within a total team environment, that enables the University at Buffalo to successfully fulfill its mission.

I think it’s just a little vague (it doesn’t clearly delineate us from the other departments within our IT Org, for example) but I really like the fact that part of our mission statement is that our goal is to help the University fulfill its mission.

The University’s mission is a bit on the verbose side, so I won’t quote the whole thing here, but it talks about research, education and supporting development of the region, which is what one might expect from a large state research university. How and why you keep your eye on the mission is dependent on where you are in the IT organization:

• IT organization leadership needs to stay mindful of the overall mission of the parent organization to ensure that their strategic planning aligns with overall organizational goals. The mission statement should inform prioritization of existing and new services and should be the driver behind innovation of new services.
• Middle management can use the mission to drive tactical decisions and present strategic recommendation to leadership. They can also use the mission to communicate the impact of their work and it’s relation to the organization’s overall mission.
• Engineering staff can use the mission to motivate their own work as well as inspiration for tactical and strategic recommendations to management and leadership.

In these examples, the mission serves two purposes: a focus of decision making and a rallying point to build and maintain energy. Depending on how excited you are about the mission of your organization, the later may be a stretch.

But how can your mission help you with the minutia of daily IT work? How can it help you decide which hardware firewall to purchase or how to best configure your Web server or select a testing framework for your development environment? It’s really not that much of a stretch if you focus on outcomes when you are planning. For example, when selecting a new firewall, you’re probably considering price, performance, overall security, configurability, etc. If you’re struggling with your decision, consider the outcome you want the firewall to achieve. Consider these possible desired outcomes:

• Reduced cost of maintaining software firewalls on individual servers
• The private network is protected from external attack
• Increased capacity for securely sharing resources over the external network

I’m sure there are many more. You could easily look at this list and say those are all desirable outcomes of installing a hardware firewall. But with a variety of desired outcomes, it can be hard to make a choice because each may point to a different solution. That’s why it’s important to prioritize. This is where your mission comes in handy. If your mission includes providing your services in a cost effective manner, the first outcome may be your primary driver. If your mission is driven by providing your services securely, then the second outcome may be your main motivation. If your mission includes language describing collaboration (which would probably be the best fit for ours) then the final outcome may be best. If your mission it lengthy and mentions all of these things then it’s not much help and that’s what I’m a fan of terse mission statements because they can really focus decision making.

Keep in mind that this is as much an art as a science, but I believe that outcome based planning is one of the best ways to ensure mission alignment. I hope to write more on the topic of this kind of planning in future posts.

Information technology is about solving problems. Unfortunately one of the most overlooked steps in the requirements process is clearly defining the problem to be solved. To do so we need to work with the users of the proposed system to make their tacit knowledge — the knowledge in their heads — into explicit knowledge in the form of specifications written on paper, on a whiteboard or, at the very least, verbally communicated.

The problem with problems (yes, I just wrote that) is that not only are they often difficult to express, they are often overlooked entirely. Problems are the what of the specifications process and even if we are good IT Professionals and don’t jump right into the technical solutions, too many times the specification glosses over the problem to the functional solution or the how of the specification.

Who Defines the Problem?

Perhaps this is in part because only the customer can define the problem statement. We can spend all kinds of time working with the customer to define scenarios, use cases, personas, business rules etc. and it’s common to do so because it’s easier to contribute to and drive that discussion. It helps that there are all kinds of books and other resources on the design portion of the specification process. The problem statement, however, is entirely the purview of the customer and there’s little support out there for how to write them and there is a particular lacking of resources on this topic specifically aimed at the IT Professional.

The problem statement is the mission statement of the IT project. Without a clear vision for what we’re trying to achieve, there’s no consistent way to ensure that we’re staying on track throughout the course of the project. So the problem statement serves two primary purposes: to provide a starting point for the specifications and to serve as an ongoing focal point for your solution.

One of the thing that I find most troubling about problem statements is that, in reviewing examples and advice on developing them, I get a sense that most IT Professionals think their customer is the problem. They describe what the system being implemented is supposed to accomplish but I rarely see an actually problem in there. I know that the term Problem Statement usually refers to something broader than just a sentence or a paragraph that describes a problem per se, but the fact that the problem being solved by the proposed system isn’t in the specs is still troubling to me.

A Little Advice

So here’s my advice: first define the core problem that the system is intended to solve. Remember that we’re talking about an IT system here and the problem should be stated as an information problem to be solved by technology. Next, since we’re talking about a system — a complicated big thing made out of smaller, less complicated things — consider that there are sub-problems to be solved as well. So consider developing a hierarchy of problems that the system should solve. This should provide you with guidance when making implementation decisions. If you find that functionality is being proposed that is not within the scope of the problem statements you created, you need to either remove that functionality or revise your problem statement.

There’s certainly nothing wrong with revising the problem statement, just make sure you do so strategically. Also, keep in mind that not every problem defined by the customer is best solved by a given system… but that’s another topic.