When given a choice we prefer to adopt an Agile approach. We believe that following an Agile approach leads to a far superior final product. We also believe that Agile is much less risky. So this post is unashamedly biased in favor of Agile.

First, a brief description of the two types of projects:



Waterfall-type project:

A waterfall project typically has a set deadline for set functionality.  Many businesses like this type of project because it seems predictable and makes it easy to get a budget approved for the project.

Process: Plan, Build, Test, Done.

Problems:

• Trying to predict accurately while software development is very unpredictable.
• User Requirements Specifications are usually insufficient and open to interpretation, which leads to errors.
• Scope Creep is time-consuming to manage and often “sneaks” in due to unclear specifications. This puts pressure on the development team to deliver more functionality in the same amount of time.

Agile-type project:

An agile project is typically seen as a recurring monthly expense instead of a big capital expense. Features are delivered frequently  (typically every two weeks) and the project carries on for as long as it is delivering useful functionality.

Process: Plan, Build, Test, *Repeat Repeat Repeat

Problems:

• Unable to promise specific features at a specific deadline far in the future.
• Difficult to work with businesses with a “waterfall” mindset (most big old businesses).
• Difficult to get project approval when hard-and-fast promises can’t be made.

Advantages:

• Deliver what’s useful, not “what the spec said”.
• Deliver useful features early.
• Detect problems early.
• Embraces change.

Why Projects Fail

Projects can be considered failures for many reasons. The most common reasons that I have observed are:

1. Budget Overruns and Late Delivery – these two usually go hand-in-hand.
2. Incorrect Functionality delivered – the client expected one thing and the programmers built something else.
3. Technical Problems – for example: the system is too slow to use, or it doesn’t integrate with another critical system in the software ecosystem.

Below is a list of ways to combat these three problems in either a Waterfall or Agile project.

Problem 1: Budget Overrun/ Late Delivery

Waterfall:

• Add extra time to mitigate risk. For example: estimate 13 hours for a 10 hour task. Not optimal. Expensive.

• Track progress against milestones to ensure the project is progressing on schedule. (The problem with milestones is that they can give a false sense of security. When you think something is “Done” it might not really be. “It’s done! (except for the styling, or integration with external system X)”)
• Work overtime if needed to catch-up.

Agile:

• Frequent delivery means most important features get delivered early.

• If less important features are late it is not such a big deal. The system is constantly improving and maturing.

Problem 2: Technical Problems

Waterfall:

• Do lots of prototyping in the first stage of the project to try and spot technical challenges.

• If caught late it may be too late to do anything about it. Major losses.

Agile:

• Will be picked up early due to continuous early delivery. Project can then go a different direction, or cancel project if absolutely necessary (at least it will be early).

Problem 3: Wrong Functionality (incorrect assumptions)

Waterfall:

• Write very detailed user requirements specification. (The problem with User Requirements is that they give a false sense of security. Now matter how explicitly they are written, they are still open to individual interpretation and interpretation may not be what the author intended.)
• If caught late it may be too late to do anything about it. Major losses.

Agile:

• Agile embraces change. Frequent delivery ensures that the correct functionality is delivered and any “mistakes” are detected early. The client is continually evaluating the system and can change direction as required.

Enjoy the holidays and we’ll see you all in 2012.

My aim is to load a good clean database of South African cities linked to suburbs (I’ll write another post about that later) something a lot of people seem to want but no one seems to be doing very well, and those that have very clean data don’t open it up. I also wanted a relational table with SQL Server Geography datatypes, simplegeo or openstreetmap aren’t close to a perfect dataset. Ideally I wanted to load the geographic polygons that define the cities and the suburbs, I also want to load the bounding boxes, centroids and radius that encapsulate the suburbs.

I know there is some open street map data out there but Shaun Trennery, who I trust implicitly and is the tech brain behind safindit.com pointed me at YQL. Yahoo’s data seemed the cleanest and I decided to use their data to load the suburbs. (By the way, YQL is amazing: you can perform crazy queries like find all sushi restaurants in San Francisco “select * from local.search where query=”sushi” and location=”san francisco, ca” and Rating.AverageRating=”4.5”” awesome hey?) I have a JSON file of WOEIDs (Where on Earth ID) that define South Africa, this can be retrieved with a simple YQL query or download it here: LocationsZA.json. I wrote some code to parse these and load them into a SQL Server table that I’d designed (again – that post to follow).

I was having a problem loading Yahoo WOEID polygons as Microsoft.SqlServer.Types.SqlGeography objects in SqlServer2008. This fails on insert for certain polygons with “24200: The specified input does not represent a valid geography instance” exception which, typical of Microsoft, will take you here, and well, that doesn’t tell you anything you don’t’ already know (a side note, System.Data.SqlClient does not support the Geography type so you have to make a reference to Microsoft.SqlServer.Types).

I wanted to investigate if these polygons were in fact polygons. I also want to visualise the other elements of the WOEID (centroid, bounding box, radius etc) so I wrote the following ugly web form (let me reiterate I hate web forms and NML only build ASP.NET MVC but this was a quick prototype to see what the polygons looked like on google maps mostly taken from this post).

Figure 1 as you can see only slightly adapted from the codeproject. (click to enlarge)

The following image illustrates Yahoo’s idea of the Constantia WOEID Polygon.

As you can see it’s pretty obvious why the polygons won’t load, they aren’t true polygons. So that’s my warning don’t use yahoo polygons for suburbs rather uses bounding boxes where you can be sure that your geospatial queries will return trustworthy results. I’ve also noticed that in some instances Yahoo doesn’t even store the polygon.

So I had another chat to Shaun Trennery and we are keen to open this data up, and possibly build a geographic wiki app that allows anyone to modify the polygons, the administrators will have the final say. This will allow us to add suburbs yahoo isn’t aware of like those being defined by the Name Your Hood guys (if you know how much I initially disliked the Name Your Hood project you’ll find this ironic) and also define parent suburbs, for example Constantia is the parent suburb Bel Ombre, Nova Constantia, Constania Hills, Klein Constantia , Rust en Vrede and Alphen for example.

I’d be interested to get feedback from the GIS gurus on the best sources of Country/Region/City/Suburb/ information. Please also let me know if you are keen to collaborate on this mini project.

When we relocated from the Upper East Side’s ground floor to the 6th floor our finger print recognition system had journeyed sans the override switch, an oversight on the suppliers part, but I’d signed off on the job so I must accept the blame for this.

I arrived at our offices, my mind spinning dollar signs as lost development time mounted. The team were without access to their workstations or wifi, at least they’d located coffee in the shape of Vida’s Upper East Side store. Fortunately we can all work remotely, so I sent everyone home and we successfully conducted a virtual stand-up, I can’t fault my staff’s diligence and we ultimately had quite a productive day.

After discussing the system fault with manager of Bytes Technology Group who installed the system, I was told that they would cover the bill to remove the glass from our front door. Tracy sourced a glazer to remove the glass pane from the door, and Bytes sent over a technician to fix the system and add a manual override switch. The Bytes technician spent most of the day installing the switch. When I returned from lunch I caught the technician at the bottom of the lift, “Are you going to show me what you’ve done?”

Exhibit A:

Me: “You’ve used 20mm screws that can easily be ripped out?”

Technician: “Yes, that’s a problem.”

Me: “But I wouldn’t bother ripping the screws out as I can just cut and short that exposed wire.” [Shorting the circuit is all the wire does.]

Technician: “You’re right, that would be a problem.”

What baffles me is that this supplier, and the unsupervised technician, expect me nonchalantly place the security of all our hardware, servers, mail servers, backups and data into the inert hands of an inexperienced technician. I was horrified! What would happen if I didn’t know any better? (An MSc ought to do it, but not everyone installing a finger print recognition security system has a basic knowledge of electronics.) I requested that he reinstall the system, “I want the screws to go through the door and be fastened on the inside of the door and I absolutely don’t want any wires visible”

And then I was presented with this.

Exhibit B:

Me: “But it isn’t attached to the door.”

Technician: “Didn’t think it had to be.”

Me: “And you’ve used the same 20mm wall plugs.”

Technician: “Yip.”

Me: “The same plugs that are easily ripped out! And if I don’t rip them out I can just unscrew the screws.” (normal bi-directional screws)

Technician: “Hmmm, ja that would be a problem.”

#FFS

It dawned on me, software is no different, in fact it’s more critical, you often can’t see what is being delivered. The client may not even completely understand what it is they are buying. They test the application visually but often don’t know what is happening under the hood, and yet they have to trust the development company with their entire business. What’s crazy about that is not the trust that is required but the fact that often clients will treat suppliers like second-class citizens and not as partners. I’m glad I can call all of my current clients, partners and not just clients and I think they would do the same.

Trust is a key aspect of any relationship, from personal to commercial, and it is something that is established, not immediately assumed. Trust, certainly on an industrial level, starts with communication, reputation and diligence and builds from there. It’s not something I take lightly, it is intrinsic to my working relationships at NML, beginning on interpersonal levels and extending to our clients, I believe we as a company exude this culture of trust to our partners.

As Gary Vannerchuck said in his SxSW keynote speech: “no matter what business you’re in, you’re also in the business of customer service,” and all businesses need to start “giving a solid f#$&” or else they’re going to lose.

Ps. As an aside, the technician once worked for me as an intern graphic designer, bizarre I know – but it is true. Yes he’s gone from being a one-time aspiring graphic designer to security system installer – it’s obvious why he did such a shitty job, his current job isn’t his calling. He probably doesn’t enjoy it, and can’t wait to get off site. Follow your calling people, find what you love doing and do it well. A lack of passion shows.

Pps. To make matters more awesome, on Friday I sent the bill to Bytes for the glazer and the managers’ boss sent it back saying he never authorised the R695 payment to the glazer – talk about disconnect.

In the dynamic software development industry you need to experiment, adapt and find out how to be super-efficient without sacrificing quality. It’s a challenge.

In this series of blog posts I will describe in detail the things we do and why those things work so well.

Problem Nr1: Broken Code

Any reasonably sized software application (or website) is essentially a complicated machine composed of inter-related components. A large part of a software engineer’s job is to simplify that complexity by compartmentalizing  parts of the system and writing code that does what it’s supposed to but is also understandable . After all – how can someone maintain your code if they struggle to figure out what it does?

Yet, despite all our best efforts Errors still creep into the application. For example: I may innocently make a small change to how a financial calculation is done, and unwittingly break several other web pages that I did not realize would be influenced by my change. And the breakage may only be noticed several days later, making it very difficult to try and determine why the pages broke.

Unfortunately this is just the nature of software development: “Bugs Happen”.

Wouldn’t it be great if there was a way to protect against breaking code? And to detect bugs as soon as possible?

Problem Nr2: Being afraid to change code

The world is moving at a rapid pace. Businesses change and need to adapt to be able to take advantage of gaps in the market.

Nobody understands this better than a software developer who has had to change how a system worked even before they were done implementing it completely first time ’round.

Unfortunately changing code can be scary, because your change may break existing features without you realizing it. So often developers try to make changes in a way that is unlikely to break something else by “sticking” the code on the side of the system where it interacts with as little other code as possible. This obviously results in a poorly integrated solution that is difficult to maintain. It results in bad code.

Wouldn’t it be great if existing code were easy to change? That developers could respond rapidly to business demands and fearlessly change the entire solution to better fit the business requirements?

The Solution: Unit Tests

We believe Automated Unit Tests help alleviate the problems mentioned above. Automated Unit Tests promote developer confidence and helps protect against bugs.

When we code a new feature, we write two types of code:

1. Feature Code: Code that is the feature requested by our customer.
2. Automated Test Code: Code that tests the Feature code.

A single website that we  build will be covered by hundreds of unit tests. We run these tests several times a day while we are busy extending or modifying the client’s code. We use a test runner developed by JetBrains. Its output looks as follows:

Have a look at the output of the test run above:

• For the client project we ran 534 tests. It took less than a minute to run all the tests.
• Tests are nested underneath each other. Different sets of tests test different parts of the system.
• 1 test failed and the message at the bottom describes why. When a problem like this is detected it has to be fixed immediately.

The important thing to note here is that we always run all the unit tests, as opposed to only testing the small part of the system that the programmer is busy changing. This means that the entire system is tested several times a day for defects.

What we test

A software solution is made up of layers where top layers depend on bottom layers. For example (this is simplified):

• The User Interface layer displays web pages to the user. It relies on…
• The Business Logic layer that knows about business entities and how they behave. It relies on…
• The Data Access layer that knows how to interact with a database to save and load data.

One way to test would be to test the User Interface Layer and let it interact with the layers below it.

We do not test this way. Testing all the layers together leads to slow tests that are brittle and hard to configure. It also means that the causes of failures are difficult to track down because the bug could be anywhere in numerous layers.

We prefer to test layers and individual components in isolation. We do this by supplying fake implementations of the layers on which the code depends. For example:

Testing layers individually means our tests execute quickly and errors are very easy to pinpoint. We prefer writing lots of little tests as opposed to a few big ones.

A single “Business Logic” test may do the following things:

1. Configure “Fake Data Access” to return certain data when called – For example: return a fake Person when called.
2. Call a “Business Logic” operation – For example: calculate investment income for a Person.
3. Check result of the operation – was a calculation done correctly?
   3a.  Flag the test as “Failed” if the calculation did not yield the expected result.

Conclusion

We believe in writing unit tests because:

• Unit tests are much faster than manual testing. The entire system can be tested several times a day.  (although we obviously still do lots of manual testing to pick up issues that unit tests can’t detect)
• Unit tests give developers confidence to make changes and keep the system clean and easy to maintain.
• Unit tests save time (it’s very time consuming to find and fix broken features once the code has gone “Live”).
• Unit tests make everyone sleep better at night.

As the Mother City stirs into action below me, I make my way down to the gym for my morning workout.  It’s one of the (many) perks working at NML and, not only is the gym conveniently located for a pre‑work workout, but NML subsidises our membership fee too.

Paul has set himself the challenge of making NML the best possible environment for the team to work from and there is a strong focus on work/life balance here.  Our office space plays a big role in this regard.  A converted residential loft space in the Upper East Side, it creates a relaxed and informal working environment that benefits from incredible views over the City, the harbour and the mountains.

Work/life balance is a key element in NML’s work ethic.  There is a degree of flexi-time to our working hours, so long as we’re all in by 9.30am, and Paul encourages not working more than 40 hours a week as anything over that leads to burnout – I’m told it’s one of the key tenants of The Agile Manifesto.

Our office is based in Woodstock meaning we don’t have to commute all the way to Town and a couple of us carpool in to work together from Tokai making the commute easier and more social.  There is a finacial incentive not to use a parking bay. Most of the team are members of the gym downstairs and the residential layout of the office means you can go downstairs, have a great workout, come back to shower (or even have a bath if you want!) and eat lunch (NML has a steady supply of sandwich ingredients, bread, various condiments and a snackwicher!) before getting back into the ‘work’ zone.

I use the term ‘work’ here, but really, each member of the team is so passionate about what they do, that it doesn’t really feel like work.  The developers get to while away their days coding, fixing bugs, testing new technology and creating new techie stuff, Andrew gets to do his copywriting, Raoul manages the team and makes sure the clients are happy, Paul gets to focus on the next innovative growth steps, reading, meeting and general plotting and planning and I get to spend my days ensuring that life in the office runs smoothly (each to their own!).  More often than not, the team have their headphones on to help them stay focused and in the ‘creation zone’.  Although we have an informal policy of ‘Do not disturb when the headphones are on’, it doesn’t mean there is any disconnect in the team.  Truth be told, NML’s team is one of the most functional teams I’ve worked in.  Every morning we do ’standup’ where we each recap the previous day’s tasks and what we plan to accomplish today – it provides a chance to report our progress, raise challenges in projects we’re working on, ask for help where we need it and just generally ensure the whole NML team is up-to-date on what’s going on.

The standup exercise is just one of the tools we use for staying connected as a team – we have others too: the Braai (weather permitting, the team downs tools at 4pm on Fridays and we head to the main balcony for beer and burgers).  Then there is the much loved Coffee Pot (fresh brewed coffee is a staple part of the NML diet!).  That’s not to say we don’t do the usual ‘team building’ type of events.  I recently survived my first game of action cricket as the only girl on the team and the guys were really sweet about the fact that I actually lost runs!!

All in all, life at NML is pretty darn good and I can honestly say, I’ve found exactly the type of job and working environment I was looking for and in the country that I love to boot!

I’m doing my utmost to create the best possible environment for a small, skilled development team to work from. This part of the recipe is simple, create a beautiful, stimulating and relaxing environment to work from. This helps maintain our great team, and attract new members.  In turn, this leads to great quality software for our clients, and happy clients means plenty of on-going work.

Some time ago, after almost completing the move, I posted this picture on twitpic :

http://twitpic.com/53pgjh.

To the untrained eye there doesn’t seem to be much amiss in this image, besides being out of focus and slightly under-exposed, but to the trained agency eye of a brand manager who happens to see that picture, and also happens to have the account for the most ergonomic chair out there, this image is crippling. A blue plastic chair from Makro just doesn’t cut the mustard in my new office, and doesn’t do my back any favours. By the same token, a R100 black plastic in/out tray functioning as a monitor stand borders on crude.

Fortunately, Kastner & Partners and FormFunc were on the other end of that twitpic, and before I could say chiropractor they’d sent over two of their Liberty Chairs, and M2 Monitor Arm and a Freedom Chair, which is honestly one of the sexiest inanimate objects I’ve ever seen.

The monitor arm itself is a revelation. I have a passionate dislike for cables, I honestly believe they contribute to our stress levels by their very presence. With my cordless keyboard and mouse this monitor arm allows me to remove all cables from my desk, as the cables run inside the arm to the underside of the desk.

The monitor arm also allows me to move my keyboard past my screen, and get my screen up in line with my eye. In the 20 years I’ve spent behind computer screens I’ve never felt so comfortable looking at my screen.

Given that we spend a good 8 hours a day behind our screens, this arm is well worth every cent. It seems manufacturers of monitors with the fixed base have forgotten that humans are all different.

Besides its sleek lines, the Freedom Chair’s simplicity is ingenious, with three inconspicuous controls my the chair can be perfectly adjusted to perfectly support my back. Echoing the designers Niels Diffrient’s motto “Comfort is the lack of stress”.

And if this seems like one of those terrible product placement blog posts, that’s because it is. The difference here is that I wholeheartedly endorse this brand and their products, that and my computer science antics aren’t extreme enough for Kastner and Partners’ other brand – Redbull.

There are two instances I should expound, my minute of airtime on the panel precluded these:

1) Immediately after starting New Media Labs I sold a 40% share to Global Vision for a significant sum, technically share capital, or maybe an angel investment, as opposed to VC, but that could be construed as semantics

2) Nearly two years later I “bought” back that share in a debt/equity swap after Global Vision owed me nearly the equivalent amount of money. The reason I don’t see that as receiving VC, while others might, is that Global Vision bought into a partnership with a services business in order to establish an affiliation with New Media Labs and have access to the skills I had already brought to the company. Venture capitalists almost always buy into product companies as opposed to service companies.

I know that as a service company New Media Labs is very unlikely to receive venture capital, we’ve developed quite a number of products over the last four years but it is very hard to sell the idea of a service company becoming a product company to VC and this article below explains why. It also explains what most service companies that are profitable, and have a good client base, should do about finding venture capital. With respect to New Media Labs, no article has resonated for me more in the past year than this one, even the numbers resonate, albeit in rands rather than dollars. Below is an essay that could only come from experience. Have a read, tell me what you think (my take homes in red).

What Should You Do With Your Crappy Little Services Business?

(This post originally appeared on TechCrunch)

There’s a line of thinking in Silicon Valley that you should build product businesses rather than services businesses. This thinking is largely driven by the venture capital industry (and a

It’s nearly impossible to get a services company financed by VCs. You’re a small fish.

So pervasive has this thinking become that on several occasions startup companies with profitable & fast growing services businesses have come to me wanting to show me the product businesses they created internally to see whether they would be financeable or whether they might be able to create “spin outs” that could be financed.

A great recent example of this was a successful group of entrepreneurs who had created a company that will do $10-12 million in revenue at their system integration business (read: services business) in 2011 after having done $5 million or so in 2010 and $2-3 million in 2009. They feel very confident they can hit $18 – 20 million in 2012.

They have created two internal technology “products” and wanted to figure out how they could turn their services business into a product business that could be financed. This team is talented. They wanted advice. And probably some money. I gave them advice I don’t think they were expecting from a VC,

“Don’t raise venture capital for this business. Ever. And stop effing around trying to create a product company.”

It is advice I give entrepreneurs often as I have written here on why most businesses should never raise VC.

Why Shouldn’t Most Services Businesses Raise VC?

Well, let’s look at this exact situation:

• I don’t have access to their actual financial statements but let me make some reasonable assumptions. It would not be a big stretch to image a well run service business like this making 15-25% net profit margins. Early in a services business there is usually no profits as the company reinvests in hiring people to grow, but by $20 million in sales the company should at least be pulling in 10% profits (if not more) depending on how much is reinvested.

• So assume that in 2012 the company would do $20 million in sales and $2 million in profits (10%) and 2013 they would do sales of $25 million and $4 million in profit (16% net margin) and then slow growth in 2014 to $30 million and $6 million in profit (20% profit). That is $12 million in profits over 3 years.

• The founders could reinvest this in growth (0% tax, focus on future equity growth) or take the profits of $12 million and divide amongst the founding partners. Assuming there are 3 founders and they own an equal amount (33%) then they’ve just taken $4 million each in profits and note that this is at a qualified dividend tax rate (currently 15%) versus an income tax rate (35%). True, the 15% rates will likely go up in the future, but I doubt they will approach the income tax percentage level.

• The thing is – even if your services business is a smaller scale than this – you have complete control over the decisions about where to take the business. There is no shame in making a few million dollars in profit and paying yourself dividends while still owning a large percentage (if not all) of your business. It’s how things are done across the country outside of Silicon Valley.
• The minute you raise VC you have one option – grow & try to become big. No VC is interested in dividends – they want growth. That’s the right answer for VCs.  It may be the right answer for you. But it might not.

• Trying to turn a successful services business into a product business is getting the cart before the horse. If you really want to do a product business then hire a professional manager for your services company, quit that job and focus 100% on your product company.

Why Build a Services Business in the First Place?
There are at least two types of tech services businesses in my mind:

1. Service as a bridge to a product business - One of the best ways for young startups to finance their business without any dilution is what I call “customer financing,” which is mostly only possible in businesses that target businesses rather than consumers. Customer financing often comes in the form of your company agreeing to build a product with a “sponsor” customer or two and helping them with the rollout / implementation. Often in this strategy you end up giving them the product for free and bill them only services fees. You own the IP you create.

The benefits for the customer are: a mostly custom-built product addressing one of their internal needs, the focus of a very talented young startup focusing on their business need & free product – potentially for life.

The benefits for you are even more clear: you get to build a product raising significantly less external money (if any at all) and therefore no dilution, you get a customer who will help you figure out the real requirements for your business and you have your first real reference client lined up, which should help with future funding and with future sales.

If you set out to build this kind of business you just need to be sure you don’t become a permanent consulting business by default. The “customer-financed” type of tech service business is never frowned upon by VCs – unless you’ve been doing it for 2-3 years with no product business to show for it, by which point they assume you’re the second type of services business.

2. Services for services sake - The type of business that is generally shunned in Silicon Valley is the “pure services” business like consulting, system integration, value-added resellers (VARs), customer support businesses, outsourcing companies, etc.  I have already outlined some of the economic reasons these can be good businesses as well as the one of the most important – retaining full control in your business.

But the broader reason that I often suggest them to entrepreneurs is that they’re much easier to build than product businesses even though they’ll never become Google, Twitter or Facebook. Trust me – it is far easier to persuade a business to pay you for your services (a concept they readily understand) than it is to persuade them to buy a totally new product concept and pay for that product.

“How much is that software really worth? Who else is using it? How much did they pay? Wait, I’m only paying “X” for my Salesforce.com licenses – and you want me to pay “Y” for your product? Who are your competitors – how much do they charge?”

I could go on-and-on with all of the sales-blocking messages you will hear when you try to charge for a product. I’ll repeat: everybody understands paying for services. It’s pure irony. At my first company we would have a product sale of $80,000 where the customer would grind us to get the fee down to $70,000 but would readily pay $25,000 extra for “implementation & post-sales support.”

We were building a VC backed software business so I had to focus on the product business. But this lesson in business was never lost on me. And some of my former teammates are now building really awesome services businesses in the exact same field and they own 100% of their companies.

Even tech blogs know this. You struggle to get advertisers to pay your CPM rates and get your page clicks up in a business where you become a near commodity to ever other website out there. Yet you can run a conference and mint money. If it’s well run, people readily pay for conferences and sponsors readily pay to become platinum, gold or silver sponsors. Tech blogs can theoretically scale, tech conferences are pure service businesses.

But How Do Service Businesses Grow?
I’m not saying the scaling a services business is easy – it’s not. One big challenge is how to grow the company. You end up needing to add staff and take on more risk without knowing what your future demand will be. There are a couple of ways to think about this growth.

1. Start with a network of independent contractors (1099′s)- When you’re a young company with 3-4 people and you land work that requires 7-8 it can be daunting. You don’t necessarily want to take on the extra employees and risks. I recommend that you establish a network of contractors who want to do similar work to you but don’t know how to sell projects or to build a company. They’ll be glad for the occasional extra work.

2. Vendor financing – When you start to win business – let’s say as an implementation arm for tech / business products or as an ad sales team for large tech / media businesses – you can often get financed in a small way by your vendors who are all to happy to have a bigger ecosystem of implementation houses. They won’t do this before you prove yourself but once you hit a minimum scale this is always an option.

3. Angel financing – just because VCs won’t back this kind of business doesn’t mean angels won’t. If you can show a few million in sales and the ability to return dividends in the near-term there are always smart businesses professionals who will consider financing this. What are there other choices these days – money in a bank at 0.5% interest?

4. Bank financing – OK, so this isn’t immediately likely to come from Wells Fargo, but there are tech banks like Silicon Valley Bank or Square1 Bank that are in the business of financing startups. If you can show regular cashflow and are willing to put your profits into their bank you can often fund expansion this way.

Final message on financing – just be careful not to let your fixed costs get too high as a young services business. In a booming tech market like 2011 it’s easy to think your business will always expand. The problem with service businesses is that when the economy turns revenue & profits take a really big and quick hit. Those companies that have a largely variable cost base and make the tough decisions survive for the next boom.

Why Shouldn’t Service Businesses Become Product Businesses?
If you build a true “technology services for services sake” business at some point you’ll likely build technology products as part of your projects where you either own the IP or you own in jointly with your customer or business partner.

This is where many service businesses make mistakes and go pear shaped. They get “product business envy” because they read too much TechCrunch about their product brethren raising money at crazy valuations and getting sold at even crazier ones. So they set out to build a product business within a services company.

A few problems arise. Firstly, they don’t realize how hard product businesses are. They mistake their successes in selling services as a competency in selling products. This is a huge mistake. Secondly, they often ramp up their cost base to accommodate these costs, which when a down market hits they are more effed than those that stay focused. Finally, the focus on the product (envy) means that they take their eye off of their core business, which is services. So the core business suffers.

I saw this first hand. My first career was at Andersen Consulting (one of the largest services businesses in the world). We built a hugely successful global services business yet we never got over our product envy from watching our tech clients. So we created internal software projects and all of the internal consultants on those projects became blowhards who thought they knew how to create software product businesses.

We stunk at every product we ever created. We had no sense for gathering real customer requirements. We over-spec’d products. We built for our over-intellectual selves. I can’t think of any great software tools ever created internally by Andersen Consulting. We were a great services business. Period.

What Should Services Businesses do with Their Product Businesses?
So back to my advice to the company I recently spoke to about spinning out their tech business or raising VC. My advice wasn’t to shut down all product / IP initiatives but rather to be clear on their purpose and how to monetize them.

1. Products as a service sales machine – My dear friend Franck Meudec in Paris knows this best. He has built some internal technology products to support his services business. They are “loss leaders” for his core business. In stead of going in and trying to hold the line on how much to charge for these products he can tell customers, “Sure, we’ll give you our planning software at cost if you decide to work with us.”

His business is booming. These products help him win his core sales. He is not confused about which is the horse & which is the cart. He is building a services business. Instead of owning 1% in options to join a startup tech company he created his own tech services business. He is the majority owner. Higher risk, higher reward than joining as a junior employee somewhere else.

2. Products as a key differentiator – Another important reason for having internal IP in your services business is as a key differentiator against other services businesses. If a customer is faced with two equal choices for companies who can implement Salesforce.com – how do they choose one other than references & price? Imagine if you had built a few modules on top of Salesforce.com that made that product more effective? Even if you didn’t charge for these it would sure increase your sales hit rate.

Tech services business in booming markets are mostly about how fast you can sell, implement, manage quality, hire and sell some more. In a down market IP can become a huge differentiator.

3. Products as a gross margin bump - Finally, it should be said that in a services business often your implementation rate becomes a commodity relative to others in the market. If you can make an extra 10% on each sale by selling your “ad on” products that are at 90% gross margins not only will you increase your win rates but you’ll also add valuable profits to your bottom line.

In summary: I’m not advocating that companies are crazy to try and be product companies. In fact, that’s all that I fund as a VC. But I don’t want the narrow world of venture-backed companies and the trade rags that report on them to dissuade the overwhelming masses of potential entrepreneurs from building meaningful businesses that are both fun and economically rewarding.

With that said, recently I had the opportunity to port what we had there to a Silverlight version and therefore happily jumped onto the task.

I’m proud to introduce the Silverlight COP!

ESRI Silverlight Viewer

I cannot take too much credit. It must be known that the ArcGIs Silverlight API is very easy to dive into due to ESRI’s excellent online samples (http://help.arcgis.com/en/webapi/silverlight/samples/start.htm). I also had some initial help when I found a post online where a guy by the name of diligentpig had already started such a port (for the love of me I can’t find that original post, so if he’s out there and stumbles upon this post, I’m apologizing). None the less, his version was in chinese and VS2008, which I upgraded to english, VS2010 and Silverlight 4.

Functionality that my version includes:

• Your standard navigation commands of Zoom In, Zoom Out, Full Extent and Re-center Map.
• Layers widget with the ability to set the ArcGIS Dynamic Layers you want to suscribe to in a configuration file. My demo is pointing to the following sample ESRI dynamic services: Census USA Info (http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Demographics/ESRI_Census_USA/MapServer) and Cool stuff in California (http://serverapps.esri.com/ArcGIS/rest/services/California/MapServer)
• Overview Map, Bookmark widget
• The Standard ESRI Navigation Control in the bottom left
• GEO RSS Feed widget and the ability to set which Geo RSS Feeds you want to display via the configuration file
• Ability to Switch between a street map, topography map or imagery map and also the ability to set their services in the configuration code. My demo is point to the following sampe ESRI services: Streets – http://server.arcgisonline.com/ArcGIS/rest/services/ESRI_StreetMap_World_2D/MapServer Topography - http://services.arcgisonline.com/ArcGIS/rest/services/ESRI_ShadedRelief_World_2D/MapServer Imagery – http://services.arcgisonline.com/ArcGIS/rest/services/ESRI_Imagery_World_2D/MapServer

If you are interested in seeing the source code, please don’t hesitate to contact us at NML.

Lastly, for a bit of fun, click the links below and have a look at the original flash version of the ‘pulsating red ring’ and my silverlight version. Which do you prefer?

Silverlight Red Glow

Flash Version

or

Silverlight Version

The cool thing about this is it was all done in Expression Blend 4 using story boards and animations. Click the code snippet below to see how it was done.

Red Glow Expression Blend XAML Code

New Media Labs were privileged enough to be offered the opportunity to make their mark on the success of the 2010 FIFA World Cup when we were hired by Aurecon to architect and develop an Information Portal to be used by a Transport Operations Centre (TOC).

The purpose of the TOC was to provide the public with information about any public transport mechanism at any time leading up to and during the running of the 2010 FIFA World Cup. Secondary to this, the TOC was to monitor all public transportation issues that may have arisen and feed notifications of these issues to the relevant authorities.

Central to the management of this information was the Information Hub component of the TOC. We envision this as being served by a Microsoft SharePoint 2010 (MOSS) installation, allowing for a rapid deployment given the timeframe of the project.

Aurecon was briefed to develop the simplest possible solution that utilised off-the-shelf products as far as possible so as to minimise the risk and lengthy time frames implied by custom development. New Media Labs were happy to provide their knowledge and expertise in web technologies, SharePoint 2010 and Rapid Application Development.

The Information HUB provided the following key functional components to the TOC:
• Information Wiki
• Call Logging
• Information Request
• Status Updates of Facilities
• Complaint Reporting
• Incident Reporting

In addition to the above, the HUB also provided:
• Functionality and responsibility split between various roles and groups, e.g. Call takers and Supervisors
• Workflow
• Spatial Awareness via interactive ArcGis Maps
• Connectivity in the form of RSS and GeoRSS Feeds

Information Wiki
The wiki was used to provide information to the Call Takers, other role players within the TOC and the general public in a structured, logical and consistent manner. The information presented by the wiki component of the Information Hub was a mixture of “traditional” wiki-style static information and “dynamic” information, presented by web-parts provided by MOSS.

By utilizing Wiki Pages provided by Sharepoint 2010, we were able to quickly and effectively build a wiki for the TOC which was also easily updatable by members of the TOC during the tournament.

Fig 1: Information Wiki

Call Logging
The starting point for interactions with the Information Hub by Call Takers was a wizard-based dialog. This dialog was the starting point to kick off the various required workflows and also acts as guidance for the Call Takers, whilst logging the calls answered.

Fig 2: Call Logging – Landing Page as seen by a call taker

Fig 3: Call Logging – Answering a call as seen by a Call taker.

Information Request
One of the primary functions of the TOC was to handle incoming calls from the public and answer any questions that they may have. Call takers could utilize the Wiki to locate the information required to answer any questions. At the end of the call, the system would allow for the call taker to capture the details of the question, if they were able to answer it, and if they need to respond to the caller once an answer has been found. If an answer was not given, then this would initiate a system workflow, which ultimately would generate tasks to supervisors indicating that the information was not available and the wiki needed updating which they could then do.

Fig 4: Information Request – Capturing question details and if it was answered.

Status Updates of Facilities
A status update is linked to some physical entity and reflects a property of that entity that may change over time. Two examples include a measurement of how full a parking lot is, or how congested a segment of road is.

We utilised the SharePoint 2010 ArcGIS map web part to graphically represent the various FIFA 2010 World Cup Transport related facilities for Port Elizabeth, and stored the facilities status values in an underlying SharePoint list.

Fig 5: Status Update via SharePoint 2010 ArcGIS map web part.

Complaint Reporting
Monitoring complaints from the public by the TOC allowed for rapid notification to the relevant Stakeholder or Representative of the issue at hand. Workflow was incorporated to provide feedback to the reporting individual and inform them that the issue has been reported to the relevant authority.

Fig 6: Complaint Reporting – Capturing of the complaint details by a call taker.

Incident Reporting
Incidents are events that have taken place that may or may not require some sort of action by a role player who is either internal or external to TOC. Whilst some notifications may have emergency aspects to them the TOC’s role (and the Information Hub) was one of information sharing, and thus, the design of the system was to allow the relevant parties to be alerted to an incident, to monitor the progress of the incident and to track when the incident was resolved.

Fig 7: Incident Reporting – Capturing of an incident by a call taker.

Roles and Workflow
Within the TOC were several different roles and group, each having their own responsibilities and actions within the TOC. We leveraged off of SharePoint’s role based functionality and utilized the built in workflow engine to quickly implement the require business processes.

Below is an example of such a process.

Input State	Action Required	Role	Next State
Open	Action to relevant party	Supervisor	Actioned
Actioned	Must be resolved or re-assigned to a party who can resolve	-Technical Manager -Representative -Stakeholder -External	Closed
Escalated	Immediate resolution action required	Supervisor	Closed
Closed	None		-
No Action closed	None		-

Fig 8: Tasks generated by workflows within SharePoint, assigned to the Supervisors group.

Spatial Awareness and GEORSS
Within the TOC were several wallboards mounted across the centre. A wallboard is defined as being any large-format display screen that is placed in a location such that it is visible and easy to read for two or more role players.

One of the primary wallboards was the Common Operational Picture (COP). This wallboard was primarily used by the Supervisors, but was visible so that any person within the TOC is able to quickly and easily get an overview of the current operational situation. A COP is a map representation of the area in question with various icons and indicators.

We utilized the Sample Flex Viewer supplied by ESRI and implemented various widgets within it provided functionality such as displaying various ArcGIS layers such as bus routes and facilities, Incidents captured within Information Hub via GEORSS feeds, real time vehicle locations and vehicle tracking, and Status Updates from the Information Hub.

Fig 9 : Incidents on the COP via a GEORSS Feed.

Fig 10 : ArcGIS Layers depicting a Bus Route on the COP

Summary
By utilizing the power of SharePoint Server 2010, workflow, roles and leveraging tools from ESRI ArcGIS server, New Media Labs and Aurecon were able to quickly implement a system which aided in the effective management of transport for the 2010 FIFA World Cup in Port Elizabeth.
We look forward to working closely with Aurecon again on any more future opportunities and projects.