To quote a simple definition I found online, scope creep is: “The tendency of a project to include more tasks or to implement more systems than originally specified, which often leads to higher than planned project costs and an extension of the initial implementation date.”

In other words it basically means a feature that was initially thought to be simple that’s exploding in scale. For us unfortunately this has already happened a few times with the next major release of LandlordMax. We wanted to offer Quickbooks support but that’s been postponed because of the scale. We also wanted to offer check printing but that’s been pushed to a future version as well. The latest feature which is experiencing some serious scope creep is full email support within LandlordMax. The good news is that we’re going to push this one through because I think we’ve finally limited it’s scope creep (and it’s much smaller, speaking very relatively).

That being said, I thought it would be an interesting read to go through our experience of what email support entailed, and just how quickly it exploded in scale.

The initial requirements were extremely simple. There were only two:

1. Provide the ability to send emails within LandlordMax directly through a mail server and through Outlook.
2. Provide the ability to import and export information (contacts) between LandlordMax and Outlook.

Both of these features have been highly requested for some time, and we thought it was time to add them in. Sounds simple. Send off an email, and import/export information. Nothing to it. Ah, if life were only that simple. Once we started to drill into the details of how to do this, it was no where near as simple as it first looks.

Before we go on, let me quickly ask you to make an estimate as to how long it would take to implement these two requirements? Take a second, or a minute, or whatever you think is reasonable, and do a quick cursory estimate. Write it down. We’ll compare your original estimate with another estimate at the end of this article and see what the difference is. My guess is you will be shocked.

Getting back, today I’ll only cover the second requirement because it’s the smaller one of the two. If I were to cover the first requirement (sending emails) it would be much longer. However to help you in reviewing and coming to a better final estimate I will finish off the article with questions on issues to be considered for the first requirement (sending emails within LandlordMax).

Let’s start with the second requirement, “Provide the ability to import/export information between LandlordMax and Outlook”. That should be simple. Just connect and share information. Ok, the first question is how do you connect? Do we build a connector? Do we buy a connector? What versions of Outlook do we support? Simple questions often have larger repercussions.

We initially started by looking at what was involved in building our own connector but quickly dropped this idea because it was not cost effective. Firstly we’d need to figure out how Outlook works, secondly we’d have to test each version of Outlook we’d want to support, and thirdly we’d have to continue supporting future version of Outlook. This is not where we add value for our customers. Therefore we decided to purchase a third party connector that will do this for us. Now comes the task of looking for a vendor that can do this in a nice, clean, simple way, and that doesn’t cost a fortune. All the while giving us a financially feasible way of redistributing the connector embedded within LandlordMax. We eventually found one that works with Outlook 2000, 2002, 2003, XP, and 2007. Great! One thing done.

Now that we can connect to Outlook, how do import/export information back and forth? What will the screen look like? What information will be exchanged. How do we know which contact we import are tenants, vendors, landlords, etc.? How do you import more than one at a time? What about contacts that don’t fit into these categories? What about synchronizing the data (if a change occurs in one will it be picked up in the other)? There’s a lot of options and choices here. And above all else, how do we do this in a very intuitive and user friendly way. If we didn’t have this last requirement it would be a lot easier. But that’s our main differentiator. We simplify the lives of our customers. We spend the time figuring out how to do it easily so that they don’t have to fight with the software, that’s why we’re the “EASIEST Property Management Software”.

Therefore, to answer the questions:

How do import/export information back and forth?

With the connector we decided to purchase this is just programming code.

What will the screen look like?

We’re still struggling with this one. We’ve got a good first pass implemented but we’re ironing out all the usability issues. Always trying to make it simpler. By the way, although I might be skimming this answer, it’s a very large one to which a lot of time has already been spent!

What information will be exchanged?

We’ll try to import and export as much information as possible. What this means is that we have to figure out all the mappings between the data in the two different products.

How do we know which imported contacts are tenants, vendors, landlords, etc.? How do you import more than one contact at a time?

This becomes a big part of how the import/export screen components will be drawn on the screen. Will there be drop down menu’s to select a type of contact? Will it be … ? The list goes on. We’re still determining the best solution. As an aside, if you only allow the user to import one contact at a time, this issue goes away, but that’s not a viable solution. Many people have lots of contacts, in the hundreds. It’s really not a viable solution to ask them to import their contacts one at a time.

What about contacts that don’t fit into these neat categories?

This one might seem simple, but it resulted in a huge scope creep! Maybe you have real estate agents you want to store within LandlordMax. Maybe you have bankers, etc. So what we ended up with was a completely new Workarea (section) called Contacts. Simple, just a new area to enter in data. Not so fast!!!

With each new area comes filters. You have to be able to filter the data. Ok, that’s not too bad. But wait, what about reporting. You need to be able to generate reports on the new Contacts. So we added Contacts to the Reporting workarea and create several new reports. Is that it? Nope. Still more. On top of creating the new tables, you need to be able to support upgrading existing databases to handle Contacts. Ok, we’re done now right? You would think so but not yet. The list just goes on. Basically this ended up being a costly extra that we hadn’t planned. But the benefit is that we also end up with a new feature that other people have been requesting, a way to store other contacts.

What about synchronizing the data (if a change occurs in one application’s contact will it be picked up in the other)?

For the current version we’re not offering synchronization of the contacts. That just too massive a feature to implement. Although it might seem simple at first glance, synchronizing data is complex. It’s so complex that it extended the release beyond when I’m willing to accept. So for now a synchronization feature has been postpone.

To quickly give you an idea of the effort involved in synchronizing data between the two applications, here are some common issues that must be correctly dealt with. Which data has already been synchronized? For example I have a contact in Outlook called “Stephane Grenier” and I add him to LandlordMax as a landlord. Then on another attempt I go to synchronize again. Is this the same contact? How do I know? What is the identifying characteristic (the unique key)? Is it the name? If so, what happens if I change the name to “Steph Grenier” because of a typo? Do I create a new entry? What about the existing “Stephane Grenier”? Do I delete that one since it no longer exists? As you can see it quickly escalates in complexity to deal with all the possible scenario’s.

What generally happens with synchronization algorithms is that you have a basic set of rules for which the user corrects the data afterwards. Merging data has always been tough. There are many tools just to merge two text files (it doesn’t get any simpler than that). Text files! Not contact data across different applications in different sections of the applications. It’s not a simple task. Although nice, we’ve decided that it for now our customers can just re-import data if they want to. It’s more valuable to our customer to get the release out sooner than holding it back for this feature. And holding it back could be quite long…

So far we’ve just talked about scope creep for the second requirement, importing and exporting contacts from Outlook. This is the smaller of the two requirements by far. I’ll leave it as an exercise to the reader to think about the sending of emails as a requirement. Here are just a few of the issues we had to resolve:

• How do you select which method to use to to send emails (directly through the mailserver or through Outlook) without annoying the user with popup choices each time?
• How do you pick which email address to send it from?
• How do you support multiple send email addresses?
• Do you record sent emails? If so where? How do you access them later?
• How do you create the body for the emails? What about spellchecking? What about advanced editing (bold, italics, etc.) How much effort will it take?
• How do you send an email to multiple contacts at once? What if they’re different types of contacts? A tenant and a landlord?
• How do you send a generated report as an attachment?
• How do you send an email to all your tenants? What if you want to exclude some tenants?
• How do you filter the contacts (say tenants) you send the emails to (for example Current tenants only)? How do you make this generic enough?
• How do you send an email to all your tenants with only some variables different (for example send each of your tenants reminders that their rent is due in three days, with their specific amounts displayed in the email) – By the way this is one of the larger email features we’ve postponed for now.
• How do you send emails to people not in your contacts list? Can you create new contacts directly from the send email window?
• Can you receive emails? (this won’t be supported within LandlordMax for now either).
• How do you integrate email on every data screen to easily offer the ability to send emails to the current person you’re looking at (for example tenant, vendor, etc.)
• How do you integrate sending emails in the list view to the selected rows?
• How do you make all this very user friendly and very intuitive (above all else!!!)

And this is only a quick list that I came up with right now on the spot. The list goes on. I know we faced several other issues. And I’m still expecting a few more new ones to make their appearance.

At this point I’ll ask you to re-estimate the total effort needed to implement the initial two requirements. Rather than just say it’s a lot more, I recommend you go through the exercise of actually thinking about it for at least a few moments. What did you come up with? How many times larger was your final estimate? Notice I asked “how many times”, not “what percentage”. I suspect that for many of you it’s many times larger.

What’s happened is that a simple requirement has exploded in terms of scale and effort required because we hadn’t fully analyzed it beforehand. I doubt it would have been possible without getting our hands dirty trying to implement it. Without hindsight it’s almost impossible. Having gone through the experience it’s easy for me to direct you in the right direction in terms of effort required. But without this hindsight it would be almost impossible. How much effort do you think is required to support Quickbooks? What about check printing?

Along the way we’ve had to make hard choices on what features we’re going to implement and what features will have to be postponed. This is what software development and project management is all about. Making choices. Right or wrong decisions have to be made in terms of what gives you and your customers the best value for the money. Scope creep happens. Features that weren’t planned need to be implemented. A good project manager will be able to, at least more than often than not, make the right decisions as to what features are in fact necessary and which are truly scope creep. This is the fun of project management.

---

Permalink to this article          Discussions (5)

---