It’s funny how a company who proved to be so bad at online sales could be so good at managing their online presence.

I posted my complaint at 9am and by 1pm Comcast had found my blog post and responded to it online.  And within minutes of my reply to them via email, I was in contact with somebody at the Comcast home office.  The problem was resolved in a matter of a day.

OK, well done Comcast, really.  Every company should be as on-top of their online presence as you are.  Just a few Google Alerts would allow any company to receive an email whenever somebody blogs about their company or brands.  It’s easy, it’s free, and it just plain works.

Oh, and I did get the Extreme plan ($150/month) and it is indeed very fast.

So I go through the checkout process and at the end I am greeted by Da in a mandatory chat window.  Here’s the unedited chat session, which lasted just 6 minutes.

Da(Thu Oct 23 09:14:31 EDT 2008)>Hello. Thank you for choosing Comcast. My name is Da and I will be processing your order. It will take me just a few minutes to pull up your order information in our system. I will let you know if I have any questions.

Da(Thu Oct 23 09:16:01 EDT 2008)>Can you please verify the last four digits of the social security number on your account?

Gregory_(Thu Oct 23 09:16:49 EDT 2008)>****

Da(Thu Oct 23 09:16:28 EDT 2008)>Thank you.

Da(Thu Oct 23 09:17:10 EDT 2008)>You current have the bundle for cable, internet and phone.

Da(Thu Oct 23 09:17:34 EDT 2008)>If you want to upgrade to ultra tier, it’s an additional $20 per month.

Gregory_(Thu Oct 23 09:19:02 EDT 2008)>that’s fine…what’s the total monthly bill?

Da(Thu Oct 23 09:20:47 EDT 2008)>I’m sorry but I am unable to upgrade the internet speed. The system is stating that the  ultra speed upgrade is only available for customers with the $114.99, $129.99 or $159.99 bundle.

Da(Thu Oct 23 09:22:22 EDT 2008)>Is there anything else that I can assist you with today?

Gregory_(Thu Oct 23 09:23:02 EDT 2008)>odd

Gregory_(Thu Oct 23 09:23:18 EDT 2008)>nope, that’s all.

Da(Thu Oct 23 09:23:12 EDT 2008)>This could be a glitch with our system because the $99 bundle is grandfathered. Please contact our technical department at 1-800-266-2278 for further assistance.

Da(Thu Oct 23 09:23:15 EDT 2008)>I’m sorry that I could not be of more help to you today. Thank you for your time! Goodbye.

Sale…lost.  Could you imagine being so close to a sale and letting it walk away?  Isn’t that astounding?  Where’s Da going?  Is there another customer waiting who is even closer to buying?  How about “Let me check with a manager because this should work…”?  Could you imagine standing at the checkout counter at Walmart, only to hear “Sorry, the scanner’s not working right…have a nice day.”

Obviously I’m not going to call the Comcast technical support line in order to buy more products.  Ironically, I was about to ask Da to upgrade to the Extreme plan at $145/month.  And I would have upgraded my entire package too.  But I didn’t feel like spending the next 45 minutes in a chat session trying to pursuade Comcast to let me spend more money on them.

Thanks to Danielle, Louise, and Michelle!  We’ll knock this project out of the park, don’t worry.  It’s an aggressive schedule but we’ll definitely get it launched on time.

Given the economic meltdown in the past week, I figured I’d get some new ads on Google.  I wanted to get some ads that people would see if they wanted to outsource their software development in an effort to trim costs.

Look at the minimum bids for the keywords below.  Who in their right mind would pay $25 per click?  Are they insane!?!

Thank you for the continued business, Mike!

LinkedIn is not a popularity contest.

What good are 500+ connections if you don’t actually know any of them?  Are you suddenly more important (more popular?  more profitable?) if you have 1,500 connections on LinkedIn?  The goal of networking is to build relationships with people, not to collect their email addresses and add another notch on your Rolodex tally.

Today I have 185 contacts in my LinkedIn profile, a number that may decrease in the near future.  I’m going to remove anybody whom I am not 100% comfortable calling and just saying hello.  If I have to call you, explain who I am and where I work, then honestly I don’t think there’s much reason to include you in my professional network.  And that’s what LinkedIn is supposed to be - a professional networking resource.

Here’s my LinkedIn Network Quality Test.  To be in my LinkedIn network (not that it’s an honor), a contact must fit this criteria:

1. I trust you.
2. I like you.
3. I have had more than one email or phone call with you at some point in our relationship.
4. I want to do business with you sometime in the future, if we don’t do business together already.

That’s it.  These four criteria embody the exact opposite of the LION philosophy, which is simply: if you have an internet connect and can type my email address, welcome to my network.

Software projects have certain phases, as do all projects.  We have conception, brainstorming, kickoff, development, QA, implementation, etc.  Being a programmer myself, I know the parts of the project I like best.  I like the brainstorming and the kickoff, but by the time implementation rolls around I’m pretty much done with whatever it is I’m writing.  I’m sure many developers feel the same.

Now that I’m in management, I want to get a better understanding of developer productivity.  This matters a great deal to me since unproductive developers affect my bottom line.  With 52 software developers at Stature, if all our developers have just one unproductive day it equates to over two months of unproductive business days.

Wow, OK - I just scared myself with that statistic.  The bottom line is that it’s important for Stature to keep its developers productive, motivated, and happy.  Happy developers are productive developers, and productive developers pay my mortgage.

Alright, enough intro.  Here’s the meat of my argument:

I believe software development productivity dips immediately after the first deliverable, when the client first sees a functional version (or subset) of the product.

The “client” is whoever will be using the software.  For Stature, it really is a client.  But for an internal developer, your client is probably a business user at your company.

Here’s what happens:

1. The client works with the development team to design the product.  There are meetings, brainstorming sessions, and eventually some sort of spec.
2. The development team disappears for a period of time.  At least a few weeks if it’s a decent sized project.
3. The development team codes like mad and is highly motivated and productive.
4. The development team prepares for the first deliverable, probably a subset of functionality or a functional wireframe version of the application.
5. The client views the first deliverable.  It is probably presented to the client by the development team, and the client is walked through the functionality and progress to date.
6. The meeting ends.

Soon thereafter, developer productivity starts to dip.  Why?

1. This was the first time the client actually felt the application.  Specs are one thing, mockups are another, but to actually use the application is entirely different.  Now that the client has used the product, the first set of changes are about to come.  These changes will come soon - if not at the meeting itself (in the form of “hey, can we…” type questions), then within days afterwards.
2. Once the developers receive the changes, they need to make unanticipated changes to their code.  Even worse, immediately after the meeting the developers are probably working on the very parts of the product that are going to be changed by the client.

It is during this period that overall productivity dips.  The project isn’t moving forward with the same energy and productivity as before.  Sometimes the developers start to get that “Us vs Them” mentality, where the they think the business users are neophytes who don’t understand software development (hint: business users don’t understand software development; nor should they).  The developers are forced to abandon some of the cool parts of the code (hey, they spent 3 days getting that treeview just right!) and resent throwing the code away.

This productivity dip is inevitable but the affects can be minimized:

1. Warn the developers that the client is going to do this.  Just knowing it’s coming can make it easier to deal with it.
2. Immediately after Milestone 1, we often have the developers work on tertiary parts of the product.  Things like reports, admin-screens, password-reminder screens, etc.  We have them work on the parts of the application that need to be written eventually (but are often left to the end) and don’t require much client input.  While they’re working on this functionality, the client has the time to thoroughly (and thoughtfully) review the first deliverable and provide feedback.  In the meantime, at least the developers aren’t continuing to code something that may be altered by the changes being written up by the client.

The First Deliverable Dip is a real thing.  It can last for days or weeks depending on the changes requested by the client.  Normally the changes are more pronounced when it’s a brand new project that only existed on paper before the first deliverable.  In those projects, it’s really hard for the clients (users) to know how the product is going to work until they get time to play with it.  But with a little planning and lots of patience, it’s a part of the development cycle that can be managed.

And honestly, I don’t blame the clients one bit.  Imagine designing a car on paper.  Do you really think when that car is delivered from the manufacturer, it would feel exactly like you anticipated?  No way.  The radio controls may be a little awkward now that you actually get to use them.  The seats may be a little uncomfortable.  There may be a blind spot.  It’s the same with software projects - you just don’t know how it’s going to feel until you use the product.  That’s life.  Just plan for the changes and everybody wins.

So I gave Cuil the same test I give every search engine - and it failed miserably.

1. A search for Gregory Silvano didn’t pull up anything special.  And if the first page doesn’t include my LinkedIn account, then sorry - it’s not a very good search engine.
2. A search for Stature Software returned nothing worthwhile.  We’re not a hugely important site on the web, and that’s exactly the point.  Most sites aren’t hugely important on the web and that’s why I need the search engine.  If you search for Stature Software on Yahoo, Google, or MSN you’ll get our web site at least.
3. It was slow.  Too slow.

I’m no Google lover by any stretch, but Google wins this fight.

As I was driving him back to South Station yesterday, I listed all the things I think are important for a Project Manager at Stature (or anywhere, for that matter).  I mentioned the obvious things, like: communicating with the clients, making sure you understand every facet of the application, keep in touch with the developers frequently so you’re on top of schedule slips, etc.

But then I told him something that, the more I expanded on the idea, I realized it was the most important skill of all.  I told him he needs to learn to finish the project.

Software projects can go on forever.  Literally.  They can be tweaked and tweaked for months on end.  This is beneficial to no one, but especially for a company like Stature.  We need to finish projects to maintain profit since nearly all of our projects are fixed-price and we don’t issue change orders (see our 3 Guarantees).  So to have a project run over by a month is a big deal for us since we can’t recoup those costs.  Software Projects don’t end naturally - they need to told to end. 

If I were a Project Manager, I’d want to be known as The Closer.  The guy who wraps up his projects on time, on budget, and to spec.  If another project is running past schedule, I want to be the guy they bring in to restore order and get the project done.

In the coming weeks, I want to expand on this topic and discuss the tricks we’ve learned over the years that allow us to close a project.  It’s something you learn through experience and observation, and I think with just a few high-level rules any Project Manager can become The Closer.

We started down the path of DotNetNuke and some commerce modules, but in the end it was easier to just code it ourselves.  Although very powerful, the DNN commerce modules were just too limiting.

We’re using C#, ASP.NET, and SQL Server 2005.  They already have an Authorize.net account, so the credit card processing is very easy through their API.  The store supports features such as pricing matrix, related products, out-of-stock messages, shipping, tax, filtering the products by the registered user’s state of licensing, and full integration into their CRM system.