Undocumented Features

A Way to Better Meetings, Projects and Communication

February 1, 2010 – 6:17 am

Scott Berkun wrote an excellent post a while back over at his blog about stopping over-communication. He makes some great points on why over-communication happens and how to fix it. I agree with his main points, and I think they particularly apply to meetings. As Scott advises:

Overcommunication is a symptom of lack of clarity over power. If you want better communication, clarify the following:

Who is the single person who has decision making authority for decision X
Who should have input into that decision
Who should be informed when the decision has been made

What Scott’s points address, really, is people’s tendency to defer. It’s a proven theory that if a person is lying helpless on the street, the more people are present, the fewer are willing to do anything- and so it goes with meetings and projects. You *have* to do something, it’s your job, so you do- but what people do is the path of least commitment. They talk about things, rather than make decisions and take action. The act of clarifying what has to be done and who must do it immediately removes that ambiguity for everyone and gets the team moving.

This leads to how to improve your meetings and projects- always make certain that actions that need to be taken are captured, including decisions to be made. Make sure that the person responsible for the action is declared. Doing so is a basic principle in project management, but it often gets lost in the communication aspects. Calling a meeting to clear a roadblock or make an important decision is not enough; who has authority to solve the problem needs to be decided as well.

Like this post? Buy me a cup of coffee.

Popularity: 1% [?]

Posted in Communication, Project Management | No Comments »

Capital and Expenses

November 2, 2009 – 7:51 am

Some of you out there in the world are probably familiar with the terms Capitalizing and Expensing. In the world of software development, this expresses itself in these general terms: If you are building new software or new features that add value in existing software, you can capitalize the costs. If you are doing maintenance (fixing bugs, etc), then you expense the costs. They are also terms that you tend not to think about a lot other than how to report costs to the Accounting and Finance folks.

Here’s another aspect of Capital we don’t always think about. Physical assets that are Capital cost maintenance over time. If you buy an office building, it requires maintenance. If you buy a car, it requires maintenance. The bigger the thing, the more maintenance it requires over its lifetime. This is just as true with software.

The larger and complex a software project is, the more you may have in the following costs:

Hardware: servers, desktops, network equipment, etc all cost money, must be maintained, and have to be replaced.
Hosting: Hosting internally means costs within your data center- more servers, more cooling, more power, more floor space, more people.
Code: Greater the size and complexity of the software, the higher the likelihood that you will have ongoing bugs that need to be fixed. Also, you will have real costs attached to updating for security fixes, changes to the Operating System, to your web server, to the database, etc. Also, some types of systems will require constant updates. This is particularly true for software that emulates business or legal processes and evaluations.
Training: Every new piece of software requires documentation and training for your users. Adding features means revising training and updating documentation.
Liability: Software stores data and has to handle data correctly. Security flaws, calculation errors, data mis-entry, and more are all real areas where you (or worse, your clients) can end up with the wrong data in hand and making bad decisions as a result or receiving private data they were not meant to see.

These are all real costs you have to consider when building a new piece of software for your company. Sure, you may be able to justify the build based on saved labor for the business, but what about when you add additional costs for maintaining it? Does the cost still balance?

Another point to consider is are you staffed (and can you afford to be staffed) to support the product. If you had to bring in consultants to build the software because your existing staff doesn’t have the bandwidth to build it, then you should tread carefully here. Make sure to measure that your existing staff has the bandwidth to support the new product after the consultants are gone.

The biggest reason to consider this, though, is to keep yourself in reality. Two of the biggest and most common problems in companies today are rising IT costs and shortages in IT resources. Failure to consider, plan for, and allocate for the amount of work necessary to support IT projects after the project itself is completed is one of the biggest culprits that can be blamed for these problems. Be sure you think through these post-development costs before you engage in new software development initiatives.

Like this post? Buy me a cup of coffee.

Popularity: 2% [?]