The CIO’s answer was effectively, “always say ‘No’”. He essentially said they didn’t customize anything for the installation of SAP (or whatever very large solution it was…I think it was SAP) other than to deal with currencies, languages, etc.

What? Is that true? How can that be? How will the solution work? What about this unique situation here, or this odd situation over there? It has to be customized!

Actually, it doesn’t. He had a good point. He clarified by saying that the authors of the software have thought so much about how companies run their businesses, and therefore have thought a lot about their business processes. Assuming the company selected the write software solution for their industry which fits the company’s needs within that industry, and assuming they picked a good implementer (IBM, I think it was), then there should be no reason at all to customize it.

Some of the reasons companies will implement such large, singular systems like that are that everybody is working on the same system including IT so installation, training, and support can be simplified and streamlined; everyone can be on the same “page” when working with one another in the same room or across departments, subsidiaries, or the globe; and management can at least relatively easily pull together data about the organization at any level.

One of the bonus benefits of implementing the solution with no customizations is that the solutions can be implemented in much less time and for much lower cost. The CIO said the original goal to implement SAP was 3 years and who knows how many millions of dollars. He said they did it in 18 months. WOW!!! When does that ever happen in a software project!?! (Actually, it happens when the project is well defined, well estimated, everyone is “on board”, and there are no changes along the way. This actually can be true for custom software projects as well as off-the-self software.)

Getting back to the point, I agree, customizations aren’t necessary. This statement is true…but at the global level.

I don’t think it is a valid principle to apply across the whole organization and every single level when you get to the lower levels in some departments. There are processes companies have that just don’t fit into or work within the large applications implemented by large companies.

We have worked with major companies that have implemented SAP, Siebel CRM, Microsoft CRM and others. We didn’t work on those major systems. We ended up modifying existing or creating new software applications that did what those systems couldn’t do. And our applications provided a great ROI without making life simpler (e.g., they would send data to the other applications so that our applications created less work, not more).

So, yes, it makes sense at a very high, global level to say “No” to customizations. But lower down the company it is often still necessary.

• Fixed cost – The development team may attempt to estimate the time and costs related to creating a software application. The estimates are normally generated using a requirements specification document, which defines what to create in the software application. They may also add some type of fudge factor to the estimate to give them more time in the estimate to complete the project within the estimate. If the time and costs go over the estimates, then the developers cannot charge the customer more than was proposed with the fixed cost estimate.
• Time and Materials – There may be an attempt to estimate the time and costs of the software project. There may be a written requirements document to use for the estimating. Most often though, the developers will work until the application is complete, and then bill the customer for the time and costs spent.

The Fixed Cost method of estimating and proposing a project can be a good method to use, only if the estimate is relatively accurate, and doesn’t have an excessive fudge factor. If the estimate isn’t accurate then there can be serious trouble in the project. What often happens is that the developers go over their costs and time in the project, and realize they can’t charge more for the project than their additional work, or the customer won’t let them charge more for the project because it was defined as Fixed Cost. Sometimes quality and schedule in the project will suffer significantly. The developers don’t want to continue working on the project essentially for free. But the customer wants the project done. Then the developers will continue work, but the project will become a much lower priority project, because they want to work on paying projects to keep the doors open.

All-in-all it can turn out to be a very tough situation.

Some software development companies can make fixed cost projects work, but there are many more that can’t.

Time and Materials projects are also tough. They can sometimes not work out well because there is little to no clear definition of what software will be created, how it will work, when it will be done, and how much it will cost. The project’s features, cost, and schedule can creep continuously until the customer gets frustrated, cancels the project, and reluctantly pays the costs for time spent on the project.

We have found that what works best is a slight modification of the fixed cost project. That works when:

• The project plan and software’s requirements are very well defined
• There are clauses in the project’s contract that requires the customer to pay for changes to the applications features if they requests changes that aren’t in the original requirements specification documents, and
• When the developers working on the project are experienced and and successful at accurately estimating projects.

We use this last method. We make sure the requirements are well defined, no matter what type of project it is. Our contracts always have the clause which states that if the customer changes the requirements it is a Change Order, and our developers are very good at estimating projects.

By communicating with a customer during a project you can then gain control of what they know about and are expecting to happen during a project. That level of information they have about the project will then affect how they feel about the project, about your ability to deliver for that project, and to deliver on potential future projects.

Doing this keeps them informed. They feel like they have control, whether they actually have control or not. They don’t have to guess or wonder where things are at.

Communicating with a customer is a simple task to do conceptually. But when you’re in the middle of a mind numbing number of small tasks for a bunch of projects it is just another task that often falls to the wayside. Don’t let it. Telling your customer where things are at should be one of the top priorities.

One of the difficult issues with managing your customers’ expectations is what to do with bad news.  There are two ways to deal with communicating bad news. Each has it’s own unique results:

• If I communicate the bad news before or during some event in a project, the customer and I have opportunities to, discuss, intercept, and improve or work around the troublesome situation. It will be seen as unfortunate that there was bad news. But the customer will appreciate the honestly, and the opportunity to improve the situation. In the end the bad news can be turned into good news.
• If I communicate the bad news after the event in a project, then everyone can be frustrated and lose trust. You are beyond the point of being able to deal with the situation. Not good.

I know from personal experience that it’s hard to get yourself to pickup that phone to call the customer and tell them about the bad news. I have avoided the issue and not communicated at all when there was bad news, and have suffered from it. Take it from me, call them while the issue is going on and deal with the bad news soon. You’ll feel better sooner, and get it out of the way. You might even find that dealing with the bad news quickly ends up not being that bad if you have customers that have a level head.

If, on the other hand, I am communicating good news, then all the better. The customer stays happy and might increase their level of trust with you.

Additionally, it’s better to deliver good news during whatever event is happening in a project. The customer sees that as a normal, periodic report, and retains and increases their trust in you. Reporting good news after the fact isn’t bad, but can sometimes be perceived as tooting your own horn, which not everyone appreciates.

So, always communicate with your client…manage their expectations, and you will more often than not end up looking like the good guy whether it was a bad situation or not.

“We have a custom software application written by [ABC company or programmer] in [XYZ technology]. It works but it has problems. Should we keep it alive and continue modifying it? Or should we start from scratch again and rewrite it?”

That is a very good question. This question of keep alive or rewrite the software has been addressed by others in our software industry. This specific article references the recent rewrite from scratch of the well known project management tool Basecamp by 37Signals, and a timeless article by Joel Spolsky on the same topic but with the opposite view.

The summary of the two opposing points of view are:

• Rewriting is good because the old product was well done but was written for a different time, with a different frame of mind, and with old technology. Everyone will be better off with better application.
• Rewriting is bad because “You are wasting an outlandish amount of money writing code that already exists”…the loads of code debt or bad code can be fixed, a rewrite isn’t necessary.

These are both solid, well supported lines of argument. But I think they are addressing different situations. Jason Fried of 37Signals doesn’t talk about Basecamp being a bad application with bad code, just that it was great, but can be better. And let’s face it, if you follow the software company 37Signals you know they’re not hurting for money and can afford to do a complete rewrite.

Joel Spolsky addresses the other type of software application, the ones with problems, bad code, slow performance, etc for the large, widely distributed applications. He says all of those things can be fixed and the cost to the fixing is much, much lower than the rewrite. He’s write…err, I mean, he’s right.

What I like is the clarification by the blog post author, Garry Robinson, that the software application should be rewritten if either the database design really poor, or the code is really poor because the developer(s) didn’t know what he/she was doing, or both.

Garry is essentially saying it’s a matter of severity; if it’s really bad, rewrite. I agree. Issues can be fixed if the problems aren’t endemic throughout the code and database. But if they are, rewrite.

In fact we are facing that exact situation with a customer’s application. An application was built by an internal person years ago with Microsft Access and SQL Server. On their own those are fine tools to use for this situation, and a great custom software application can be written with them. But the way it was written was…well, it was not good (an understatement). The application is really hard to support, especially in some specific feature areas.

We are now working with the customer to do a complete rewrite. It will give them a solid application that won’t have the frequent issues it had before. The customer will also get new features and capabilities they couldn’t dream of with the old application.

They work with organizations from small bars and restaurants up to major restaurant and hotel chains, as well as other types of major corporations handling liquor licenses.

They deal with a lot of odd and interesting situations and save their clients huge amounts of money. It can be really expensive for a restaurant or bar to not server alcohol if there’s a problem with their licensing.

We have created some custom database applications for them over the past several years. RJ, Mark, Chris, Lori and everyone else have been great to work with.

Here’s to many more years of continued success! [klink]

My life was a lot different before I had a “system”. By “system” I mean how I would manage the work I do. I’m not referring specifically to software programming tasks, but rather to the general plethora of “To Do” tasks day in and day out to run a business.

I have taken to heart a lot of what David Allen discusses in his Getting Things Done (GTD) system. That has enabled me to become more productive, more proactive, and much less stressed. I needed some kind of method to stay on top of and ahead of this custom software business I own and run. The business used to run me and my life. Now I run it. And because I run it, I’m now able to improve and expand the business significantly.

If you don’t have a “system” yet, read that article and join his newsletter, or read his book (or listen to the audiobook version)…see if what he says resonates with you. His system might not “be the one” for you, but you should at least try something. Our world is getting every faster and busier with more unnecessary inputs. To succeed you’ll need a way to work on the right things in the right order.

I was in their offices recently working with a director and a manager on a project. While walking around the office and saying hello to various people I know at the firm I was reminded of a few things:

1. How many years we have worked with the firm
2. How much we have enjoyed the work
3. Most of all, how much we have enjoyed the people at the firm

All of the work has entailed doing data analysis and creating custom software applications.

We have enjoyed working with everyone there for the past several years, and are looking forward to continuing our great work together.

I’ll continue with Part 2 of the previous post, how I turned Nozbe on it’s side to fit how I work. For Part 3 I’ll discuss the small issues I have with how I’m using Nozbe.

After reading Michael Linenberger’s Master Your Workday Now system I realized he has some great ideas. The few that stick with me are:

• GTD (Getting Things Done by David Allen) is a good system, but can be improved
• Next Actions isn’t enough
• We all think about the tasks in front of us with a time horizon
• The tasks in front of us can be separated into groups based on urgency and important

Here’s a little background on 3 of those items so you know what I mean.

Next Actions isn’t enough:

GTD suggests putting a few important, high priority items in a “next actions” category, which you will then work on next. Any other tasks that need to be done sit in projects with dates on them. Once you finish your current next actions you then figure out what’s next by going through your various projects.

I have a lot of projects, a lot of things to work on next. I feel like I want to fill my next actions with lot’s of items, because I fear I’ll forget an item is coming up next once it’s buried in a project. At that point Next Actions would be full of loads of tasks, and then quickly loses it’s power of showing just a few important next actions to work on.

Time horizon:

When working on tasks that are in front of us we normally don’t think or look much beyond 1-2 weeks, a “now horizon”. Anything beyond that we don’t think about in much detail. Therefore, that “drop off” of thinking about our future in detail becomes a horizon beyond which we don’t see much “over the horizon”. Don’t get me wrong, I can easily think beyond 2 weeks…but when I have my head down working my daily tasks, I don’t look beyond 2 weeks.

Separate Tasks into Groups:

To deal with the issue of too many tasks in Next Actions why not first group items into things that need to be done within my “now horizon”, and put anything else in a “over the horizon” category.

Why not instead break them up into smaller “next” time periods. He calls them “urgency zones”. Michael Linenberger suggests putting items in future “next action” categories called Critical Now, Target Now, Opportunity Now, etc.

Given those ideas above I realized this twist on GTD would work better for me. But those phrases for breaking down items didn’t mean much to me after using them for a while. So, the groups I came up with to group tasks are: Today, Tomorrow, Next 3-4 Days, Within 2 Weeks, and Over the Horizon.

Now, the way I implemented this in Nozbe:

1. Create tasks to get them out of my mental RAM, assign them to projects, put specific dates on them when possible, etc per GTD
2. Created a Context for each of the task groups (Today, Tomorrow, Next 3-4 Days, Within 2 Weeks, and Over the Horizon)
3. Set items to the Context of Today for items I absolutely must do today. Set items to the Context of tomorrow for items I must or should do tomorrow, etc.
4. Each morning I review Nozbe’s Next Actions (i.e., items have automatically appeared in Next Actions because they have today’s date or a past date on them), items in the Today context, review projects with potential important tasks, and set my plan for the day.
5. Work all of my items in the Today Context, organize new tasks coming in into the appropriate projects, contexts, etc.
6. Try to close out all items in Today by the end of the day. If I can do that, then I feel really satisfied and happy, and rest much easier that night.

Overall it has been working really well. And I REALLY LOVE a lot of the features in Nozbe.

My method for using Nozbe in this slightly different way gets a little klunky at times. I’ll deal with that in Part 3 of this post series.

I bought season tickets this year so that my wife, Allison, and I could go to lot’s of games. We’ve been getting more into baseball. What makes games really interesting and fun is to score them using a scorebook.

I also bought the season tickets so that I can give tickets to customers, programmers, and others that we work with to show them my appreciation for what they do as customers, programmers, etc.

Anyway, as a season ticket holder I was selected to do a video testimonial. So, yesterday Allison and I went to PNC Park to film the testimonial. I talked very briefly about how great a wife Allison is for giving me a trip to Brandenton, FL to see the Pirates play at McKecknie Field. Such a great trip!

Apparently this video along with others will potentially be displayed before the beginning of some games. So, look for me on the jumbotron. And then tell Allison what a great wife she is for giving me that great trip!

Q: When should a software developer or company estimate the cost of the software and tell the prospective customer?

A: As early as possible. Sets expectations and allows the sales process to go forward with the customer. And if the numbers are too high, that appropriately eliminates prospective customers that can’t afford custom software. It allows both of you to move on, or to steer the conversation to a lower alternative solution.

Q: Will the estimates be accurate?

A: No, definitely not. They won’t be accurate until you can spend more digging into the project later on in the sales process and the custom software project.

Q: What happens if you under estimated at the beginning of the sales process and the final estimate in the proposal is higher?

A: Tough beans! Tell the customer you didn’t have a chance to dig into the project deeply until now, and this is the actual cost of the project.

Q: Can you prevent underestimating?

A: Yes, by going really high with your ballpark estimates…but reasonably high.

Typically in the initial conversations with a prospective customer they will tell you generally what they want in a custom software solution (very high level, no details), and then ask, “So, how much is that going to cost?”

You obviously can’t give them exact cost for a custom software project, right after you just heard the high level ideas about the project, and don’t know anything about the details. But if you have some experience in the area of custom software development you can at least take an educated guess.

But, be careful what you say when you give them the educated guess. Don’t tell them it is definitely that cost, won’t go higher than that, etc. You should couch it in terms that effectively say that it’ll be in that ballpark, but you haven’t had the chance to review the project in detail, etc. You have to be honest with with the prospective customer that you are willing to discuss numbers early, but everyone at the table needs to understand the numbers are very preliminary and will very possibly change up or down.

Being honest and upfront like this with a prospective customer can go a long way in establishing a good bond with them. If they see that you’re not afraid to discuss numbers, and they understand that they are very preliminary numbers, then you can have a open conversation about whether you’ll be able to do business with them. You are able to find out early if they are a good prospect for you, and vice versa.

This prevents everyone from spending otherwise wasted time trying to build a business relationship that, had anyone been paying attention to the signs, would have known it wouldn’t have worked out.