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.

How many of you have heard a developer say this at one point or another:

“Why on earth would they want it to do that?”

Modern requirements gathering has become a very sterile task- identify what must be done.  Don’t get into the weeds.  Describe the problem.  Let the developer solve the problem.  Where this goes astray is that, like the worker on the assembly line who inserts tab A into slot B and passes the item down the line, the developer is simply pulling a lever to make it exactly as described.  They have no idea what the goal is, so they can’t troubleshoot, they can’t add value, they can’t even tell if it does what the user intended- which is often different to what the user said to the business analyst.

A good business analyst can get at what the user’s intentions are.  The problem that I’ve found is that often the business analyst may know what the user’s intentions are, but he has no idea how the existing system is solving the user’s problems.  What the business analyst usually has is how the user thinks the software solves the user’s problems.  There may be large, significant chunks of logic hidden deep in the system that have broad implications, none of which the user or the business analyst is aware of.

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.

1.  Scope creep will happen.  It’s natural and not the end of the world.  You must manage it.  If you don’t have scope creep, either you spent too long analyzing your project in the beginning (and you can spend too much), no one cares about your project and isn’t paying attention, or there’s something else wrong.  No one has perfect scope and requirements at the beginning. 

2.  Allow enough time to gather requirements- make sure there’s time in your project to acknowledge and handle the scope creep. 

3.  Set boundaries.  There can only be so much creep.

4. Don’t be afraid to push back.

5. Keep focus on the task at hand.

6. Trust the experts as much as the client.

7.  Do your homework before you okay a piece of scope creep.

8. Keep control on your own scope creep as much as the customer’s.

 I could write a ton on all of these topics (and I might later), but I think you’ll get the gist from Six Revision’s article.  Take a look!

1) a reliable web server
2) reliable power for the web server
3) reliable physical location for the web server
4) reliable network connection to the web server
5) failover capability in the event that the web server fails
6) reliable backups in case the server crashes
7) physical colocation of servers in the event that one server site is damaged in a disaster
8) multiple network connections in the event that a network connection fails
9) personnel who are experts on each individual component of your website (available 24/7)

and so on, and so on…

See what I mean? Unless you have the budget and manpower to support a 99.999% uptime, you are wasting paper if you set that as your SLA goal. In fact, if your business falls too far short of the goal or the goal sounds too unrealistic to your people, then I guarantee that eventually your staff will become pessimistic about it. The uptime will become an unhappy point with them, an inside joke in your company, and it will tarnish the reputation of anyone who was foolish enough to sign off on it.

This line of thinking applies to other goals in your company as well. It is important to think high and stretch your people. Challenges make your people stronger. They make your company better. If you are not stretching your people, you may risk your competitive edge. Setting too unrealistic goals, however, will simply set your people up for failure- and they will remember you for it. Being set up for failure is demotivating.

For that matter, setting too many ’stretch’ goals is just as bad if not worse than setting one unrealistic goal. Your people will get sick of every single win being a struggle to the finish. They will start to whisper things like “Who does he think we are?” and “Sure, just pile on more to the load, I’m stretched too far now anyway!”. Do you want to be thought of that way by the people you lead? Or, to be more specific, do you think your people will follow someone who they think these things of?

Never set goals that you or the people you manage do not have the resources- time, money or otherwise- to reach. Stretching is good for your business. Jumping off cliffs without a parachute is not. Others can see whether or not your goals are reachable given the resources available. Your people may see this as lack of respect for them (”He thinks we’re miracle workers!”), lack of ability to plan (”He doesn’t care how many hours we work!”), or a lack of knowledge (”Doesn’t he know that can’t be done with what we have?”). They will mistake it for incompetence, and your credibility with your people will take a huge hit that your ability to lead them may never recover from.

Let’s consider a basic example.  In company X, wait time for customers calling in for support is way up.  The call center is packed; there’s no room to add staff.  Even if there was, there’s no budget to do so.  The busy season for customers is coming up; everyone knows that call volumes will be up soon.

So what happens?  Management announces that they will start monitoring call times.  They want to see the amount of time per call reduced.  Armed with this mandate, help desk managers start communicating this to helpdesk workers.  Get the call times down; you will be graded.

What will this lead to?  In my experience, this will usually lead to the helpdesk workers working harder to end the call and working less hard at properly solving customer problems.  The result will be more repeat callers and more frustrated customers.  In the mean time, call times will go down.  Call volume will go up.  Everyone will point to the fact that they correctly predicted that call volume will go up and pat themselves on the back for successfully getting call times down.  In the meantime, they’re ruining their relationship with their customers, and they don’t even realize it.

What was the right thing to do here?  One good solution is to launch a specific effort to improve the analysis going on at the helpdesk, so that you can reduce call times and reduce repeat callers.  Look for ways to make your people more efficient- don’t just mandate it with a statistic.

The lesson here is be careful what you monitor and how you monitor it.  Monitoring a statistic will usually make the statistic better, but it will not typically solve any actual business problems.  Monitoring should always be accompanied by a specific plan to do what you are monitoring better.

Why would this be an indicator?  Simple.  There is a large contingent of people out there on the Internet that devotes themselves to unlocking software for reasons both good and bad.  If you really want to ‘steal’ a piece of software nowadays, you can.  And obviously, twice as many people chose to steal XP as they did Vista.  This means that with a cost of ”free”, twice as many people thought XP was worth using than Vista.

How would you feel if only half as many people were willing to use the new version of your product than they were the previous version, even if the product was free?  Would you consider this to be any sort of success factor at all?

Me either.

What piracy tells you is a lot about the popularity and the word of mouth of your product.  It does successfully spread the word of mouth about your product further.  Word of mouth has been shown repeatedly to be, by far, the number one most successful marketing method out there. 

Does piracy cost you money?  Yes, but it’s hard to say how much.  There is no guarantee that the people who will download your product for free would have paid money for it if they could not have gotten it for free, so you cannot accurately gauge how much money you lost from the piracy of your product.  For example, who’s to say that a person who pirated Photoshop would not have simply used Gimpshop instead if they hadn’t had access to a pirated version of Photoshop? 

It is known that it can promote adoption.  Often people pirate software because they can’t afford it, in order to learn how to use it.  Later, when their careers are taking off, they buy licensed copies, so that their career work will be ‘legit’.  If the user hadn’t had access to your product to pirate, they might have adopted something else to learn on.

It can also spread word of mouth.  People who pirate software say just as good a things about your product as people who pay for it.  Word of Mouth has value.  How much?  Again, it’s hard to say.

All in all, it’s difficult to say how much piracy costs your company versus how much it benefits you.  The one thing piracy can tell you is this:  If no one is pirating your product, that says very poor things about the perceived value of your product.  Keeping an eye on how much your product is ‘pirated’ can tell you a great deal about how much (or how little) your product is desired.  It’s a key market indicator just as much as your sales are.

If you are like me, you a) like to know what expectations are, b) what your responsibilities are, and c) if there’s any tasks involve that you just hate doing.  Here’s a quick set of guidelines that you should check on to help you understand what you are getting into with a given job or assignment:

1. Does the project team or any portion of it report to me?
2. Am I responsible for creating, soliciting, documenting or approving requirements?
3. Am I responsible for creating or approving functional specifications?
4. Am I responsible for creating or approving technical specifications?
5. Am I responsible for creating or approving solution design? 
6. Am I responsible for creating, contributing, documenting, or managing the project schedule?
7. Am I responsible for tracking or leading the project?
8. How will my responsibilities change over the life of the project?
9. Am I directly or indirectly accountable for the project outcome?
10. Am I responsible for creating, planning, distributing, or delivering training?
11. Am I responsible for creating, planning, or distributing marketing and communications to end consumers related to the deliverables of the project?
12. Am I responsible for creating, planning, tracking, or managing the project budget?

Not only should you find these things out early help you determine what expectations the business will have of you if you take the assignment, it will also help you get a full scope of the project you are getting yourself into.  By asking simple leading questions such as “I’m not?  Who will be responsible for that?”, you quickly find out a lot about how much the project has been thought about, the real resources available to the project, the organization’s level of commitment to the project, and much more.

All of this should be obvious things that every project manager should know about a given project- but surprisingly, I find many times that project managers do not know all the answers to these questions even after having taken a job and managing a project for months.  Do your homework.  Find out the basic responsibilities withing your project assignments.  Your life will be easier.