Consider this approach for a moment in the light of the concept of technical debt.  Increased features and new products mean more maintenance costs.  Increased speed to market means increased bugs.  Rising technical debt means that your team will be able to contribute even less in the mid-term and long run.  Contributing new, buggy things rather than increasing the value of what you have simply lowers your perceived value to the business.

Before deciding to add new projects, products or features, ask yourself this:  is it time instead to pay down existing technical debt?  What can I do to lower support costs?  How much better can I make what I have?  Do I have any open requests from the business to solve old problems?  Can I increase my perceived value by simply focusing on lowering overhead and getting rid of ‘old’ problems that have been lingering?  Turning your efforts inward to improve now will give you a stronger position in the mid-term and long-term.  You will have lower maintenance later when you ramp up new projects, and by clearing your backlog, you’ll be surprised at how much support you will garner from your business partners.

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.

What about operations?  How does this fit in?

The reality of most companies is that they do not have seperate project-based resources versus operations-based resources.  Major operational initiatives and problems can derail your project quickly.  An over-abundance of projects can rob Operations so thoroughly that needed maintenance is ignored, and your operations deteriorate (just ask the american government about this).  Major operational problems clash with major project initiatives.  Huge political battles can ensue, creating inaction as people who need to do do the work in question instead go sit in meetings waiting for a decision on which work to do.  People end up making decisions on an island at times, just picking a direction based on their own personal knowledge rather than wait on the corporate machine to find a direction.

Rather than get lost in these situations, get a grip on your Operations.  Include them in the resource planning process.  Most importantly, include them in your prioritization process.  Is the most important project in the company more important than maintenance of the most important existing product?  What about the fifth most important product?  The fifteenth?  Which customers’ business is more important than your projects?  Customer problems can just as easily steal resources.  Not all of your customers will be more important than the development of your company’s future either.  You have to count them as part of your prioritization process, and you have to make hard decisions like this.

Doing this type of process is hard.  It is also vital to your company’s ability to react quickly and decisively to the unexpected.  You, and more importantly, your team, need to understand and agree on what comes first.

While I don’t agree with the notion that we don’t need product roadmaps, it does point out some careful slippery slopes you must be careful of when approaching roadmaps:

• Selling things that aren’t in the product yet.  It is tempting to sell things that the product doesn’t do yet, especially once you set a delivery date.  The reason you can’t do this is simple:  Just because you say it will be there does not mean that you will meet the customer’s requirements.  The customer you are sales-pitching may envision an Alerts tab to do a whole litany of functionality that you yourself never thought of.  You might meet their exact expectations, of course, but without gathering detailed requirements, you won’t know until later.  You are setting yourself up to disappoint the client.  Offering that you have something like their requirement in your roadmap, and you’d like their input is a possible compromise- now you’re including the customer in your community, and that has value, in addition to learning new customer needs.  You still run the risk that their requirements will be totally askew of all your other customers’ requirements, and then what do you do?
• You cannot plop things into your roadmap without defining some meaning to them.  “Message tab” is easy to put on the map, but unless you list at least at a high level what that means and what the specific deliverables are, you’re just doing point number one to yourself.  You have to get some scope around the stated goal before you can aim at completing it by a given date- it’s that simple.

Roadmapping is an excellent idea; the value of it is to allow you to develop a well-thought out, living plan to add value to the product that will help you grow it towards targeted, specific markets.  Without it, you’ll run into “what’s hot today” syndrome, that is, adding the most recently hot features to your product rather than sticking to the strategy- and you really must have a strategy.  Like all tools, a roadmap can be used for good or ill- be careful how you choose to use it.

Let’s say the business writes up a project proposal. They research their business process, identify key problems with it, define good goals for the project and turn a beautiful proposal over to you. Let’s say they spend a good, solid 6 months putting it together. They’ve done their homework. All you have to do is implement it.

But wait, it’s not that simple, is it? The proposal has to go to IT management (and possibly some sort of advisory committee) for approval. IT has, after all, dozens of projects on its plate, in most companies, and can only do so much. IT probably already has tons of projects started that are ahead of the proposal. Let’s say it takes 2 months to get it sold to management and approved.

Now it needs a budget. You can’t buy hardware and software without a budget, right? This is capital expenditures. It has to go through financial planning. Let’s say it passes their eyes with flying colors, again in only two months. That means that money is approved for it- starting next fiscal year.

Now that the project has a budget, it has to wait for staff to manage it. You can’t start the project without a project team. If you want to do the project effectively and efficiently, you have to take the time to search for and find quality team members. The hiring process of finding quality employees can take months.

Now work can begin, right? Wrong! You have a project proposal in hand, a budget, and staff. You need a project plan, project scope, requirements… you can’t build something corretly until you’ve defined exactly what you’re building.

As you can see, the list goes on and on. The business is impatient for a reason, and it is a good one. They need what they need now. They’ve asked for it, they’ve done their work, and now they’ve nothing to do but wait. And wait. And wait.

The business must recognize though that if they want IT to do a good job, they have to give them the time to do it. In today’s world, you must plan ahead. IT can give a business agility, but only with a lot of planning ahead to be sure the right things are in place at the right time. If you plan perfectly, sometimes you can just hand over a proposal and get a solution immediately, but odds are, it is going to take time.

Even if the solution is coming ‘off the shelf’ from a vendor, there has to be someone in IT who understands and can support the product. There has to be a server for it to go on. That server needs to be built, secured, put into the backup plan, disaster recovery plan… the list goes on and on. Solutions take time if they are to be done well.

You must also remember that it takes time for a good reason. If the business is going to use any tool, it *must* be reliable. There can be no excuses. Any unreliability is cutting into the way business is done. Cutting corners on implementation will always, always cut into reliability sooner or later with software.

The other side of this is that IT has to learn to be more flexible. More and more IT departments nowadays hide behind the project scope and requirements gathered at the beginning of a project instead of being guided by them. Business needs change over time. If they didn’t, IT would not be as valuable to the company as it is.
On the other hand, business changes. If it takes IT a year to get the project going, don’t be shocked if the business’ needs have changed already.

Be ready to adapt to the changing needs of the business, even during the middle of a project. Yes, these changes are expensive. Yes, they are a risk to the project success. Yes, scope creep can keep you from ever getting your project done. Scope creep happens, however, because business changes. If it isn’t changing, then you better be worried about your business, because it isn’t growing and evolving.

The bottom line for IT is this: building software for the business that they don’t need anymore doesn’t do anyone any good. Keep up with changing times and changing business.

The bottom line for business is this: Plan ahead. Don’t expect overnight solutions. Find the best solution to the problem at hand and learn to forecast problems in the future so that you can have what you need in place at the right time.

Let’s consider what this does for the business.

The pros:
*Abbreviations or shortened brand names enable easier communication for those in the know
*Better advertising- people ask “what is ?” and you get the chance to sell them

The cons:
*If all employees are not in the know, it impedes communication. For example: everyone probably knows what the intranet is. Everyone probably knows the company has one. Everyone also goes to use it when they need to. It’s part of their jobs. Why does it need a different name in order to communicate about it effectively? Why do you need to sell it? If you need to sell it, then it isn’t doing a good job for the company at what an intranet does.

*Employees have to learn what all these terms mean. Managers have to learn what thousands of them mean. Wouldn’t the company be better off if these people were spending their time learning to do their job better instead?

That second con is a big one. Everyone has a certain amount of bandwidth for receiving, processing and understanding information. They can only truly learn so much per given day. This is what the whole “information overload” crisis is about. If you are creating product names for internal applications that don’t need one for the sake of branding, or you are creating abbrevations for things that don’t need them, are you helping the company by eating up employee bandwidth for learning?

Certainly, corporate culture can help you spread your abbreviations and internal brands. Is this what you want to use your corporate culture for? Wouldn’t your company better profit from the corporate culture spreading values and knowledge instead?

The bottom line is this: Abbreviations are for things you already know. Brands are for selling things for a profit. Use them in the right places, and at the right times.

The fact is, some customers simply do not fit your company’s product, brand or culture.  Some customers have demands that will simply create a relationship that is not profitable for you and will drain resources away from your quality customers.  Sometimes, the customer will simply not understand what is the best solution for their own needs and insist you do a poor job.  There’s many reasons to think about your customer relationships carefully in regard to this credo.

  So how does this apply to projects?  In client-facing projects, many aspects of it are fairly obvious.  The biggest place it applies in any project is the way you deal with your team members and your stakeholders.  When your stakeholders start questioning the judgement of your subject matter experts, this is always a sign of trouble- sometimes, the SME is wrong; sometimes the stakeholder is wrong, but either way, you have problems.  When in doubt, get a consensus of your SMEs or even get a third party involved to verify your direction.  Once you are sure of your SME, though, stick to your team’s opinion.  They’re called Subject Matter Experts for a reason.  Failing to support them will show a lack of confidence in them, which in turn may be interpreted as a vote of no-confidence in your team, and it will all spiral downhill from there.

Standing up to clients, customers and stakeholders can be tough, no question, but in the end, do the right thing for the people you lead and the company you represent.

 So it goes in IT and project management as well.  Too many times, we want the business to understand that we’re thinking ahead for them, that we’re using the right technologies, making good decisions, and sometimes the business simply does not care.  It’s not that they don’t want us to make good decisions, its that that’s our job, and they don’t need to hear about it.  They need to know when we’ll make their jobs easier.  The key is understanding when you should simplify things for the client, and when you should not.  Here’s a few example cases.

When the Sponsor/client cares about the end result:

Sometimes, people just want their problem solved.  They don’t care that you’re using web services to solve their problem.  They don’t care about the database.  They don’t care about anything except solving the specific business problem that they’ve identified.  What you should report to them is when you’ll be done, when the documentation and training will be available, and when you think they’ll be able to put the solution to use.  If this is what your client wants, then anything else other than updates to these three pieces of information likely just irritates them.  The result is everything to them.  If you talk about all the details you are wasting their time, and to them you are focusing on the process rather than getting them their result.  Stick to the basics.

When you are late on a project:

See the item before.  No matter how much the client may care about the process and the details when you’re on track, once you’re late, then they can get impatient.  Stick to the details of what you’re doing to get things back on track.  Don’t worry about the rest until you’ve solved that problem.

When your problems are not the client’s problems

The client’s problems consist of the fact that they don’t have their solution yet, what to do until it arrives, all the communication and change management around the solution implementation, training their staff, listening to their staff complain about things changing, learning how to use the new solution, providing training, and dozens of other things not related to your project/product.  The difficulties related to RPMs not compiling correctly on the linux installation are of no interest to them- that’s your problem, and that’s why you’re in charge of the project, not them.  In fact, there’s some chance that they don’t even care if you’re using linux, windows, unix, or bands of mongoose that quickly rewrite their screen every time they click on something new.  They just want their solution, and if you can tell them how you’ll make their other problems easier, that’s an added bonus.

Other times, you should share as much information as possible with the client.  Some examples are:

The solution will be delivered in phases

The client isn’t getting everything they want up front.  This complicates their lives.  Share as much as possible about what they can expect and when.

The client will be maintaining the solution after implementation

If the client has to maintain whatever it is you’re delivering, then you can’t give them enough information.  They will want and should have as much say as possible in as many decisions as possible.

All in all, understanding the right amount of information to share with the customer goes a long way towards their happiness.  Share too much, and you’re wasting their time and your own.  Keep your project reports tuned to the audience’s needs.

For most companies, the answer is wrong. When evaluating vendors, never forget to do some basic homework on their future roadmap, how it will affect your project, and how their roadmap matches up to your plan.

Here’s some things to do to prepare for major version changes during your implementation:

1) Managing the version change within your project plan and scope
If there is a version change or other major product upgrade in their roadmap, be sure that you put that in your project plan. Make sure that you put time in your project plan to evaluate the new product and adjust the project plan according to the requirements of the new product. You doubtlessly will have to upgrade to the new version to achieve support from the vendor at some point; it’s easier to change now than after you’ve gone to production with the product. Treat this essentially as a major change request would be treated, only you have the bonus that you know when it will (probably) be and can schedule this in your project. If you are tempted to put it off until after you go live, don’t. This is like all other major project changes. The later it happens in your project, the more money and resources it will take to implement.

2) Managing the version change and having the right resources
Do you have the right resources available for the new version? If the code base changes in the new version, you’ll need programmers and techies versed in that code base. You’ll need systems architects available when you evaluate the new version of the product so that you can determine if the new version requires more and/or different hardware. You will probably need a business analyst to look at the new features in the next version to consider how the way the product will be used by the company may change and improve. You may need testing folks to change their testing plans, if any are already written, and you will likely need your trainers to adjust any material they’ve done up to now.

3) Managing your resources before the version change
Do not make the mistake of doing work for the sake of having people work before the change in versions come down. There will be a lot of work that can be done beforehand. There will be some work that may become obselete with the new version as well. Evaluate your task list carefully. Don’t waste time sitting around waiting for the new version, but don’t waste resources working on things that will be rendered obselete either. It’s a careful tightrope to walk.

Last but not least, never forget to document, document, document. Keep up with your vendor’s version upgrade schedule. You will have to upgrade the product again after it is in production. This is a learning experience as to how to do that. Save as much lessons learned and project plan material as possible from your upgrade so that you can make your future transitions more smooth.

Vendor products change. This is a reality of their business model. Plan for the change so it can fit within your business model.

New ideas need owners. New problems need owners. These problems do not always fit into your existing structure. Do you have a way of dealing with these problems in your company? Is not, then you are not alone. I personally have worked for and with a number of companies that do not have a well-defined method of doing this. The bigger the company, usually, the fewer methods to bubble up ideas and problems from the lower levels.

There is a good reason for this phenomena. Usually, people in upper management are bombarded with ideas as is. They get ideas from their direct reports, from their managers, from their customers, from vendors, from all over the place. They can’t act on all of these things. They therefore insulate themselves. Departments organize themselves into tightly-knit specialized groups, and ideas from one group on how to improve another group are often ignored as coming from “non-experts”.

The thing is, this is horrible for your company. Yes, there is no way that you can act on every idea that happens in your company. Yes, many of the ideas will possibly be junk, as often lower-level employees have ideas that do not take in the entire picture. That does not change that it is vital to catch these ideas and hear them. Your lowest level employees are facing tactical problems on a daily basis. This daily exposure often will reveal patterns of issues to them that are not visible from above. You need a way of hearing about these problems and ideas, and more importantly, of finding someone and making it their job to fix these problems. At the very least, someone needs to explain what is really going on to the lower level employees.

Trapping small problems that occur en masse can be a boon to your company in many ways. It shows your employees and customers that you hear them. It gains you efficiencies. It can save you money. It also avoids a worse trap though, and that trap is powerlessness in your employees. Make your lower-level workers feel unheard, and they will begin to feel powerless. They will begin to feel like upper management doesn’t care, so they don’t need to care either. They will let the problems go unchecked. They will become unmotivated, and it will hurt your company’s bottom line.

Customers, on the other hand, will be anything but powerless. Customers can always find another vendor who will hear their problems if you won’t.

For that matter, so will your best employees. Want to see them working for the competition?

Part of management’s job is to manage. Unheard and unowned problems are, simply put, unmanaged. If you do not manage your business, you won’t be in business long. Create a process for capturing lower-level input. Make it real. Find a way for things that need to be done to get to a committee of management with the knowledge to recognize the right people to own the problem and the authority to get the right people to do so. You will be surprised how much just solving the problems you have hiding quietly in the corners near the copy machines and around the water coolers of your business will improve your bottom line and your company morale.