A surefire way to let business drive IT projects

I’ve been thinking a bit about good methods to help the business (referred to as anyone that’s not IT) drive IT projects.

So far the method I’ve observed goes along the lines of:

1. Define the problem. Sounds like an obvious step, but in IT we’re all too keen to jump to solutions. A problem isn’t that we need an ERP or a CRM system, any more than not having a hamburger is a problem. The real problem is you’re hungry. Or for the first two examples, you want to manage the resources of an organisation efficiently, or you want to track all your interactions with your customers across multiple communication channels and plan marketing campaigns.

With the problem defined we can move on to…

2. Goals. Goals are visionary statements that frame any potential solution. Think of them as solution boundaries, where the solution must sit inside. A solution scope I guess. One could be more concise information for managers. These goals are intangible and immeasurable in the sense that it’s difficult to know if you’ve achieved them, but without them your solution might not fit into the strategic direction of the enterprise. No point coming up with a mobile solution if there’s no need for it.

3. Business objectives. These are finite measurable objectives that sum up how we know the problem has been solved in concrete terms. 100% of senior management reports come from the data warehouse. Customers will be able to purchase items from mobile devices. All absolutely measurable. No ambiguity, not for the business who can say that these objectives if met will meet the current needs of the business, nor for IT and the vendors who have no wriggle room in terms of what they’re delivering at the other side. As you can see, scope at this point if already defined, and while things could change within the boundary, if work doesn’t directly support the solving of the objective then it shouldn’t be in the project.

4. Functional use cases. The creation of these further tighten your scope and clarify exactly how people, process, and technology will change to meet the business objectives. Simple use case diagrams are great for communicating with the business the functions and processes within the solution, and we haven’t even talked any technology yet. After all, the solution could be solved by just a process change. Once all the functional use cases required to meet the business objective have been agreed to by the business, the scope is effectively defined. Then these use cases in the diagram can each be turned into fully dressed use cases with the standard process, exceptions, inputs and outputs, and all information a good use case should have. An example could be Load Information or Create Campaign.

5. Business requirements. With our functionality defined and processes sorted, we can think about what technological requirements are required to achieve the use cases. Creating a campaign will require software that has the ability to create a campaign. But we’re not focusing on a specific technology, and so the business requirements must be technology agnostic, and not just written as a laundry list of features of a particular software suite you have in mind. Because that would still be jumping to a solution ahead of time.

6. Solutions architecture. This really defines the non functional requirements of the solution, and is likely to start formulating a solution to meet the objectives. This would include aspects of solution analysis and design, and takes in the input of business requirements and comes up with a solution design. Sure some of the implementation gaps may not be filed, but by this point in time a solution had now been defined and can be traced all the way back to the problem.

From here there’s the normal software implementation life cycle, including change and release management procedures. By following this process we can ensure that we’re solving business problems in a clearly defined traceable manner that the business can understand and accept.

85% of IT projects fail. I know why.

We’re all being suckered here, and not just in IT. Why does every house ever built seem to go over budget and over time?

  1. People thinking they can be Project Managers;
  2. People not knowing the true cost of change;
  3. Not having enough money to get the job done.

These problems extend to IT quite easily.

If we think of all the IT projects that fail (or if we want to feel better, think of the 15% that are successful), we must examine what it means to fail:

  1. Over time.
  2. Over budget.
  3. Didn’t deliver what the customer wanted.

The first two can be stamped out with a good Project Manager. But the real problem is number three, not delivering what the customer wanted.

Sometimes this is accidental, and sometimes this is on purpose.

One example is RFQs. Companies make a bid on IT work using an RFQ. There are two methods a company can approach this:

  1. Include as much detail as possible, and create as detailed as possible quotes. This can take a lot of time, make you seem unresponsive to requests, and have quotes that far exceed competitors (more on this in a bit).
  2. Include as little as required to gain the RFC. Externalise costs to things outside the scope of the RFC. This means you can reply quickly in the RFC process, and have quotes that appear better value than competitors.

Now lets examine the outcomes:

  1. By having high quality Project Managers, a robust change control process (that captures the true cost of change), you have a project that can be delivered on time and on budget. Depending on how good the requirements gathering was at the start, and taking into account the shifting target of meeting customer requirements now (and in the future), you might have a successful project.
  2. Or by not exploring the true scope of the project, you can easily get overwhelmed in trying to deliver a solution using nothing by elbow grease and hard work. As costs rack up, these are presented to the customer as unforeseen costs that are not typical of a project, and hence are outside the RFQ and must be paid for separately. In the end morale slips, and you have a project that met some requirements at some point in time, using most of all of the budget and time available (if not more).

So why would anybody pick option two, when it leads to near certain failure?

Greed. When we were examining those RFQs in the beginning, we were seduced by the quotes given to us, without really thinking about the true total cost of ownership. And we couldn’t since we weren’t provided with the true cost of the project by the bidders. And they didn’t do that so they could get more business. And businesses don’t punish vendors as they just see IT projects as being inherently risky.

They’re not. We’re just being taken by a ride by all the people in the system, leading me to believe that this is a systematic flaw, not just a specific component.

To fix:

  1. Businesses need to better understand their requirements. Seriously. Seriously. I’m not kidding. Gather the requirements for now. Gather the requirements for the future. Think of all the possibilities for the process. Is everything covered?
  2. As requirements change throughout the project, scope the change, go through a formal change control process (not just lip service either), cost the change in terms of resources and time, take the value of the benefits to the business and ask, is it worth risking all this (the risk you’ve calculated, and the cost) for the change to meet the requirement?
  3. Push your vendors for accurate quotes. Maybe this needs to be enforced through contracts. Sure, you didn’t foresee that the SCSI drivers were only for Windows not Linux. Sorry, that’s not a valid reason to not include the cost of having an alternative driver solution.

Finally, lets not accept that IT projects should fail. They should never fail. Never fail 85% of the time, never fail 0% of the time. I refuse to accept that projects should fail in this manner, and if they’re always failing, then we’re doing something wrong.

End-to-end Identity Management with open source?

After working with a relatively large identity and access management implementation over the last year, I’m really interested to continue working in this field.

There are with large projects many lessons learned, and plenty of times when you think to yourself “could I have done this better?”

And so, I’m contemplating getting into the Identity Management business.

But before I do, there seems to be a few different paths to take:

Each of decisions has their own pros and cons, so lets explore those.

First, supporting Oracle. Big organisations need heavy identity solutions. They have many different providers of identity data, and many different services that consume that data. While the organisation owns that identity data, they don’t have much control over where that data is stored and consumed. Hence the need for lots of different agents to interact between identity provider <> identity consumer. And that’s all well and good, but the competition for providing support in this space is fairly niche. You must be big enough to support the product, and to find customers big enough to want the product. In New Zealand, this is a fairly limited market, and is owned, unsurprisingly, by Oracle.

Next, there’s supporting the Sun identity stack. I have lots of experience on the Sun identity stack, and it has its benefits and pitfalls. The main difference between the Sun stack and the Oracle stack is open is open source (Sun) and one is not (Oracle). For customers this means not paying Sun for the software, but to implement something so significantly complex, you really must have a smart consulting company on your side, like Sun. The same arguements about being heavyweight apply here too. Only certain large organisations need this highly complex solution.

Next there’s the middleweight solution, Triplesec. Triplesec provides a lot of the functionality of the heavyweight solutions, but underpinned on relatively less complex architecture. The pitfall I’m finding with Triplesec is a lack of documentation. One advantage (or disadvantage) of the heavyweight solutions is documentation, lots and relatively thorough. Triplesec technologically is sound, but without documentation or support, you’d have to have a lot of trust in your vendor to be implementing this at the moment. Also to my knowledge, this solution is relatively untested – I haven’t heard of any large scale implementations. Not that this should stop you, but just be warned that you’re on your own here.

Finally, there’s SimpleSAMLphp. This isn’t a whole identity management solution as provided by Oracle or Sun, but more a way to take information from an Identity Source like an LDAP directory, and then authenticate against that. Provisioning new users and managing multiple disparate identity sources into one meta-identity provider this is not, but for a simple identity solution that is relatively easy to understand, support, and is widely in use (throughout all of Norway and Denmark), pretty bespoke, and using open standards. A good solution for the majority of small New Zealand companies.

And for some fun, I’ve been working on a logo for this project:

Identity Systems

Deal A Day Websites – a disruptive business model?

I’ve been thinking a little about Deal A Day websites, like 1-day, firstin, and offtheback.

All these Deal A Day websites stemmed from the idea of the main Deal A Day website in America, woot.

What is a deal a day website? Where every day there is a new deeply-discounted product for sale, and previous products for sale are removed. This generates a significant amount of excitement and buzz about the website, and ensures that people return to see the new deal each day.

Of course, all these websites are variations of this idea. woot only has one product. 1-day is a twist of fate has three. firstin has five? offtheback has one.

Currently the market leader is 1-day. 1-day has a significant amount of regular visitors, and has won the war of critical mass I believe. Like Amazon, TradeMe, and e-Bay, once you have reached a critical mass of people, there is less incentive for people to visit other sites, and hence all those other sites never grow, and the critical mass site explodes with growth.

Until a disruptive model comes about.

So I set myself thinking about disruptive models to take the 1-day crown of Deal A Day websites in New Zealand. We need to examine why there is a lot of repeat traffic to the site – new products and exclusivity. Once a product has sold out, it is gone and the customer misses out. But instead of being disapointed in the retailer, they are excited to see a good deal, and look forward to tomorrow’s deal. Combined with an active community of users who comment on products and generate content, means that there is a significant attraction for users to return back to the site.

Once a product sells out, that is a lost opportunity for the retailer, as they have lost potential revenue. Is there a way to capitalise on this?

Well we could just constantly replace items on the site. Hence it’s not a deal a day website anymore, but a constant deal website. Obviously the excitement still needs to come from having products that people perceive as being bargins. Second hand products can fit this bill. Each product is unique, and once it’s gone it’s gone, but there is always another product. If we continue to extend this concept out – for second hand markets should we let the market decide the price?

This may be a new disruptive business model – an auction a day website. Since we still need to ensure an item is sold (and not have to wait for an auction to finish), we could implement a dutch auction method where:

  • Three items are listed for sale by auction, whether new or second hand.
  • A maximum price is set by the administrator.
  • Over a period of time set by the administrator, the price decreases by a set amount at set intervals, i.e. $1 a minute.
  • If someone wants to purchase the item, they must balance waiting for a lower price against someone purchasing the item before them.
  • As each product is rare, and unique, there is a high ‘buzz’ factor surrounding the auctions.

There you have it. A new disruptive business model for deal a day websites, called Auction A Day.

As I search for “auction a day” on Google, I see no results. Good luck!

Internet Acceptable Use Policies for small businesses

So you’ve got a small business, and it’s doing particularly well. You’ve hired a couple of new people, but do they have the same ethic towards the internet as you?

Well maybe, but maybe not. It’s best to clarify these things straight away to avoid embarrassment. Have an Internet Acceptable Use Policy. Clearly define:

  • How much can they use the Internet for personal use;
  • What are acceptable (or unacceptable) sites;
  • How much can they use work email for personal use;
  • Guidance on viruses and protection on the Internet.

There are of course technological solutions to enforce these things. But they cost money, are expensive, and don’t always work. It’s better to use policies to state your approach to the Internet before people start work, and then save the grief of reacting to a problem, rather than proactively stopping it.

Satyam collapses, where’s your IT department now?

With the recent collapse of Satyam (disclaimer: not fully bankrupt, just not enough money to pay for monthly wages as I write this), this leads to an interesting question:

Where is your IT department?

This highlights one of the risks of outsourcing, which is things outside your control. Sure you’re getting a 10% cost saving over having your IT department year-on-year, but what about when your outsourcing company that’s 10 times the size of your company collapses.

Well it’s a bit too late to be thinking of this stuff now. Your contingency plan should be kicking in. You’ve got one right?

My theory about becoming rich

I’ve been thinking about what money is, and have come to this conclusion…

There is no link between working hard and being rich.

This sounds like a crazy statement to say, but bear with me. I’ve known people that have worked hard all their life, and yet, still aren’t rich. So how do people get rich?

Well you need to look at what money represents. Money represents desire of the community. So if you have something that is highly desired by the community you’re in, then you’ll have a lot of money.

So let’s explore this. If you work for a fast food store hard, you’ll never be rich. Why? Because it doesn’t pay a lot. But why doesn’t it pay a lot? Because the work you’re doing isn’t unique, and doesn’t require highly innovative skills. And because anyone can do it, then you’re easily replaceable, and hence the community’s desire for you isn’t very high, and neither are your wages.

Now look at say an Internet Celebrity that is rich. Often they get rich because they featured in a meme, which is like something of interest in the internet, such as the Star Wars Kid. Memes reflect the desire of the community, which is people on the internet, who watch the video, and click on ads, and hence pay the people in the meme (sometimes). The people in the meme didn’t have to work hard all their life, they just had to have something highly desired to the community, which is their video for instance.

So if we take a peice of land and a house that’s worth $2 million dollars, then that’s something that has obvious value because it’s desired. People want land to live from, and a house to live in. And you can see the work (or effort) that went into that house.

But if the person who earned $2 million from a meme bought that house, you would have to ask, how is that fair? How does a person who made a video of themselves twirling around a stick equal all the hard work and effort that went into building a house, and purchasing the land?

Desire of the community.

So what does this all mean? If you want to be rich, you need to be dealing in things that are highly desired by the community you’re in. Diamonds are highly desired to wealthy people, and so if you have them you’re rich. Memes are highly desired in the Internet, so if you have them you’re rich. Food’s highly desired to people if they don’t have any, so if you have them you’re rich.

And so I’m focusing on creating software that’s highly desired to large enterprises. Software that will save them millions of dollars and man-hours. By focusing on this, I can sell that software for a large amount of money, regardless of the amount of hard work that went into the software.

The software is of course, Resourcer.

Communications during an earthquake

Today, I watched a drama showing what would happen to Wellington if an 8.2 level earthquake struck the city. Suffice to say, things would be horrible.

This got me thinking, how could I help the situation. One thing I noticed was that communications was patchy at best. So how can we improve communications in an earthquake?

Solar powered wireless adhoc router.

Imagine a mesh network of lowcost wireless routers that are solar powered. These networks would consist of:

  • A solar panel producing 12 volts DC with enough current to run a router and trickle charge a battery;
  • A 12 volt battery, not unlike those used in scooters;
  • A linux based router.

Think a connection of these routers in overlapping meshes much the same way cellphone towers are. Each mesh point has a unique IP address, and knows the address of its nearest neighbours.

So what’s the advantages of this over cellphones + linelines + radio communication?

  1. Low low cost. This technology isn’t that advanced, and is pretty robust.
  2. Simple. Place the above devices into a watertight container, and place on the top of every power pole and tall building.
  3. Mass. One cell phone tower services a large area. If that cell phone tower stops working, then that area is out of communications. By having many multiple redundant wireless routers in an area, the chances of some of them still working in an emergency is greater than that of a cell phone tower.
  4. Self-reliant. Containing both a way of charging, and its own power source, these devices could work in difficult situations. If the solar panel still faces the Sun, the device could keep working for years to come. If running on battery power, the device could run for a week or two.
  5. Allows data transfer. This is becoming increasingly important in this day and age to not only communicate via voice, but data as well, such as telemetry.
  6. An open network. The Wellington City Council could provide this network free of charge, and charge people access to the Internet. During an emergency, the council could impose Quality of Service on emergency data having a higher priority than non-emergency data.

I think the benefits of having a mesh wifi network over an entire city are amazing, and can be used well in an emergency as well.

My competitor: Yammer

So I’ve found my first near direct, and biggest competitor: Yammer. Yammer is the enterprise version of Twitter so to speak, it allows you to micro-blog to a group of people within the same domain name.

Similarities between Resourcer and Yammer:

  1. Micro-blogging to corporate audiences

Differences between Resourcer and Yammer:

  1. Resourcer is a workforce utilization reporting and modelling tool.
  2. Yammer is a corporate micro-blogging tool.
  3. Resourcer doesn’t limit you to people within a certain domain name, and uses powerful organisation and group functionality that lets you create virtual organisations and groups that cross domains, i.e. projects involving multiple companies.
  4. Yammer reminds me of a chat room, except there are multiple ways of sending and receiving messages.
  5. Resourcer gives managers powerful reporting tools that allow you to view the productivity of your workforce.

As always, if you’re doing something right, then there are going to be multiple companies doing it. When I first heard about Yammer (thank you Jo), I panicked. And then when I saw they won the Techcrunch 50, I panicked some more.

But there are some positives. They launched nine days ago, and have 50,000 users already. As always, first mover advantage is significant, and often turns into the sustainable competitive advantage of a user base. Once a company decides to settle on Yammer or Resourcer, that’s a decision that’ll be made once. Hence now the battle will need to be done company to company.

And so the updated road map:

  1. Finish linking core application functionality with database.
  2. Gather requirements and building secondary application functionality.
  3. Finish information type pages.
  4. Tidy pages, do quality assurance, move project into Beta stage and open logins to other people.
  5. Write business plan.
  6. Contact angel investors.
  7. Move application onto framework, either Seagull or Silverstripe.
  8. Tidy pages, do quality assurance, move project and beta data/logins onto Gold release.
  9. Publish API.
  10. Advertise.

Living in a Desert you notice a lot of sand + Resourcer technology updates

So Resourcer is currently in a live prototype state. This means that we’ve moved past the basic HTML+CSS design stage, and are now linking various parts of the website to a MySQL database. Of course this means that various parts of the site are up and down at any one stage, but we’re getting there slowly. A roadmap from here is:

  1. Finish linking core application functionality with database.
  2. Gather requirements and building secondary application functionality.
  3. Finish information type pages.
  4. Tidy pages, do quality assurance, move project into Beta stage and open logins to other people.
  5. Move application onto framework, either Seagull or Silverstripe.
  6. Tidy pages, do quality assurance, move project and beta data/logins onto Gold release.
  7. Publish API.
  8. Advertise.

Also, I’ve noticed an awful lot of time tracking applications on the web, like Harvest, Tick, 88 Miles, and 14 Dayz (seriously, a Z on the end?). They’re all sexy web 2.0 applications that focus on the hastle that is Time Management. Where does the time go? I’d never noticed this applications until I started working myself in this space, and then saw all the other people who were there, hence my sand in the desert headline. But there’s a bit of a difference between Resourcer and time tracking applications:

  1. Resourcer tracks the time between each status update. There’s no timers, no punch in and punch outs. Managers can see how much time was taken between status updates, but that doesn’t imply the amount of time spent on a particular task.
  2. Resourcer focuses on a higher level than tracking time taken to do a particular task. Your status update could be about one or many or no tasks. Instead Resourcer is at heart a communications application across large enterprises.
  3. Where we improve on basic collaboration tools (like email and instant messaging) is our reporting tools for Managers to see snapshots of workforce utilization and to dice that information into project, or manager, or business unit specific reports.
  4. Where we improve on complex collaboration tools (like portals) is ease of use across multiple GUIs and multiple devices using our simple API, and ease of use to end customers. We want to be as simple as Twitter, but a lot more powerful to business.