My ceiling is your floor

31 October 2009

My third son was a week ago, Benjamin Micah Butel.  Benjamin means ’son of my right hand’ – and I have no idea what the person who made that up was thinking, but I know what it means to me.  It means my ceiling is your floor.  I don’t want my boys to repeat my footsteps, but to take what I’m capable of and go far beyond.  Its like a relay race where I pass the baton on (with my right hand) and they run the next leg.

As leaders, we establish innovative and creative ways of doing things, then formalise it so we can train other people to do them.  So often, this becomes a constraint when it should just be the starting point.  My ceiling is your floor.  We should be empowering people to start with what we’ve learned and go further than us with their own creative ideas.  Instead of expecting them to run the same race as you (ie do it this way because that worked really well 5 years ago), instead pass the baton so they can run the next leg of the race starting with your best and then creating their own.


Expect the Impossible

19 October 2008

“‘Impossible’ is a big word thrown around by small men and women who find it easier to live in the world they’ve been given than to explore the power they have to change it. Impossible is not a fact. It’s an opinion. Impossible is not a declaration. It’s a dare. Impossible is potential. Impossible is temporary” – Muhammad Ali.


Success is more complex than failure

6 October 2008

Well said Hugh.

“How long, you simple ones, will you love simplicity? For scorners delight in their scorning and fools hate knowledge.”


1, 2, 10

15 September 2008

Its September.  

1: What were your goals for this year?  Have you achieved them yet?  There are three months left, what do you need to do?

2: What are you going to do next year?  

10: Where will you be in 10 years?  If you can see it today, you’re much more likely to get there.

“For as a man thinks, so is he”


Entrepreneurialism

29 March 2008

What defines an entrepreneur? Wikipedia says, “An entrepreneur is a person who has possession over a new enterprise or venture and assumes full accountability for the inherent risks and the outcome.”

Technically, this is true, but its also meaningless. I think that a true entrepreneur is someone who is able to see a pain that is shared by a lot of people, then identify and deliver a solution to that pain. Entrepreneurs are motivated by creating value and serving people.

Most companies start off being entrepreneurial, but plenty gradually become the opposite – exploitational. Exploitational businesses (and people) are interested in their own gain above their customers. They are looking to make money without necessarily creating value and without serving people.

I’ve seen some companies where the culture was exploitational (and culture always comes from the top) and this came through in every facet; the way staff were treated, the way sales were made, the way priorities were set, the way customers and suppliers were treated. No value was created – it was only taken.

Xero is a good example of a company that is led by an entrepreneur and has a culture of entrepreneurialism. Everyone at Xero, whether they’re building the software, selling it or providing service (or most likely all three) are all entrepreneurs in the sense that we’re motivated to find, solve and deliver solutions to the pain that small businesses and small business owners experience today.

We know that we can’t create value for our customers and shareholders until we deliver innovative software and exceptional service and actually resolve that pain. Its a pleasure to be part of a team that is so motivated by creating value for the ~25% of the work force whose life revolves around their business.

BTW: Xero are currently hiring.


What are you building?

5 March 2008

Another interesting point from Mary Poppendieck’s talk on the role of leadership in software development is about identifying what motivates your team.

picture-3.png

The question Mary asks is,

When a team member is annoyed by their job, do they:

  • Complain (I’m cutting stones – I just want to do my job)
  • Ignore it (I’m earning a living – I just want to go home to my family)
  • Fix it (I’m building a cathedral – I’m passionate about the vision of the company)

Its obvious what kind of person you want in your team and this question highlights the motivation and attitude of individuals, but it also reflects a lot on the leadership of the team … since it is a leaders #1 job to impart the vision. Leaders also need to move responsibility and decision-making to the lowest possible level to empower people to have a ‘fix it’ attitude.


Success

9 November 2007

I like Seth Godin’s three things you need to be successful in a small business:

  1. the ability to abandon a plan when it doesn’t work,
  2. the confidence to do the right thing even when it costs you money in the short run, and
  3. enough belief in other people that you don’t try to do everything yourself.

To have the visibility to see a bad plan for what it is, the foresight to do the right thing when it hurts and the ability to gather and motivate good people requires a real leader with a real vision. Success is then what you’re left with when you’ve achieved your goals.


Scope and vision

12 August 2007

A scope document is often (or at least should be) the first deliverable in a software project and its important to get it right.

The scope document is really the ‘Scope and vision’ and can be anywhere from one to ten pages depending on the size of the project. Its an important first step that needs to happen before any real analysis can begin because you need to make sure that all stakeholders agree what the vision and key objectives of the project are.

Software projects typically go through the four stages of Inception -> Elaboration -> Construction -> Transition. The ’scope and vision’ is the deliverable of the inception stage and should provide just enough information for a go/no-go decision to be made to begin elaboration. Elaboration is where the research, analysis, detailed requirements, design and prototyping will happen before making a go/no-go decision to begin construction.

Regardless of the size of the project, the scope and vision should contain:

  1. Background and opportunity
  2. Vision / purpose
  3. Business requirements
  4. Scope
  5. Deliverables
  6. Next steps


Background and opportunity

This is the build up to the vision/purpose statement. Its the ‘what comes before vision‘ part that explains the problem that needs to be solved and provides context for the solution that the project is going to provide.


Vision / purpose

This should be a statement explaining what the purpose of the project is. It doesn’t explain the solution, but explains why you want to address the problem that you’ve highlighted. It could be for profit reasons, for competitive advantage, to improve quality or efficiency etc.


Business Requirements

The business requirements start to describe the high level requirements of the solution and its useful to separate the key objectives and goals from other business requirements.

The key objectives are short statements stating what the project will achieve. Its important that the key objectives are understood and agreed by all stakeholders up front, because all decisions made in elaboration and during the design phase need to be inline with the objectives – so if they change, it will result in incorrect requirements and design.

The goals are based on constraints that need to be applied to the project such as budget, time, resources, quality etc. It may be necessary to deliver the project in time for a trade show, or within a budget, or with available resource, so these business related goals should be defined, as they will help define the direction of the project and will also highlight risks.


Scope

After defining the business requirements and before defining the deliverables, you need to clarify what’s in and what’s out of scope. The business requirements and deliverables will focus on what is in scope, so this section should focus on what is out of scope to prevent incorrect assumptions being made.


Deliverables

Although the elaboration phase will focus on defining the deliverables in detail, its useful to propose what the deliverables of the project will look like to give a framework for the project. Will the construction be broken into phases? Are there multiple software applications being built, such as a public web site, a web application and a management system. Will sign-off be required on a formal requirements document and/or test scripts?

If it’s necessary to provide high level time or cost forecasts, don’t call them estimates because they are not. An estimate can only be made after the requirements are known and decisions have been made as to what will be delivered and how. The only useful forecasts based on a scope is to size up the deliverables and differentiate them between 1 week, 1 month, 1 year etc.

If the project is being developed for an external customer, then you need to think about and agree on who will own the IP of each deliverable and document this very clearly.


Next steps

If the purpose of inception is to provide enough information for a go/no-go decision to be made to begin elaboration, then the scope and vision document should finish with the action points that need to be taken to progress the project.

Was this helpful? Please leave a comment below.


Define your own job

8 August 2007

Steve McConnell writes about what makes his company, Construx, the best small company to work for in Washington.

One of his points is that his ‘Technical Service Providers’ can define their own job, based on the mission and strategy of Construx.

The three constraints that the TSPs must work within are:

1. Their work needs to support the mission (Advancing the art and science of commercial software engineering)

2. They need to hit their billable revenue target (most exceed it by 50%)

3. Their work needs to meet the service quality targets (any substandard offerings are pulled)

Construx provides consulting and educational services – so their mission and strategies work for them, but not for every small company. If you know your vision (why are you doing what you do), then your mission is just what you are going to do to fulfill your vision and your strategy is how you are going to deliver on your mission.

Working through vision->mission->strategy leads to clear parameters like this to work within. Every entrepreneur defines their own job, but not always constrained to their VMS. Its quite an interesting concept to also allow employees, especially in a small company, to define their own job. With the right kind of people, then productivity, teamwork, quality, culture and ultimately profitability could all benefit.


Estimating a software product

1 June 2007

Estimating the development required for a software product is quite different to estimating a project or single feature, so this is part 2 to ‘Estimating a software project‘, which suggests quite a different model for estimating when it comes to new products.

A product estimate has to be based on a roadmap, so is really a series of estimates. This would be easy if only the roadmap was clearly defined, but at the inception stage of a product, the roadmap is often being driven by the estimates, so its a big catch-22.

To provide an estimate for a software product, I use the following model:

1. Understand the objectives of the product

This is important because to create an estimate that has any value, you’ll need to divide and conquer and a good way of doing this is to create a model. As soon as you start doing this, you’ll have to start making decisions. Decisions about scope, features, roadmap, business rules, use cases etc. Its important that all of the stakeholders are clear about the objectives, so that every decision you make can be aligned with the objectives, giving you a stable foundation on which to build a model of the product.

How do you know that the objectives are stable and valid? They should be inline with your strategy, which should be inline with your mission, which should be inline with your vision. If they’re not, then they’re likely to change, in which case you’ll base your entire estimate on the wrong decisions.

2. Understand the business goals and targets

How long have you got to reach break-even? How well do you know your target market? How well do you know the competition? How confident are you in your business model? How long is the window of opportunity for the product? What are the barriers to entry? Does the product need to prove itself in the market to secure funding?

Questions like these will drive the business goals which will drive the schedule of milestones that need to be achieved, so its important to have a good enough understanding so that you can create realistic road-map schedule.

3. Set a road-map schedule

For an unfunded concept, its likely that you’ll need to have a beta version out within 3-6 months, a limited release within 3 more months and a v1 release after another 3 months. The beta product will be validating the market and proving the concept and opening the door for further funding, so hitting the business targets is vital.

4. Estimate the available resource

Working backward from the schedule, there are two main factors: features and cost. You either let features drive the cost, or more likely, let the cost drive the features. A good rule of thumb is that the cost will be 7 x the development cost – whether you plan for this up front, or end up paying for it later with delays and maintenance issues or even worse – incorrect features that have to be rebuilt.

5. Work backwards to identify what can be achieved in each milestone

Once you know what development resource you’ve got, you can estimate what is feasible to deliver in each milestone. This part will take some real work to actually build a model of the product and use the objectives to identify what the key v1 features are and what is necessary to prove the product in the market.

If the numbers don’t stack up – then its a better time than ever to realise that the product is either under-funded, under-resourced, too big or you have wrong business model and either fix it, or not waste your time & money on it.

Its also important to remember that this is inception only, and once done, there is a valid go/no-go decision that needs to be made. The right answer may be to abort the product, or to proceed to the market proof stage. After 6-12 months, the product should have proven itself , so there will be another go/no-go decision. From here, the ‘go’ decision will need to have real funding behind it to commercialise the product and take it from ‘concept to profit‘.

The bottom line is: you’ll be making hundreds of decisions through-out this process, so its important that they are aligned with the objectives and to understand that everytime one of these decisions is changed, you are departing from your estimate, which is going to happen because you have to be agile and adapt daily, but you also need to be aware of how fast the initial estimate will become worthless!


Its about people, vision and fun

10 April 2007

Most things that are worthwhile are going to be hard at some point – if they weren’t, they wouldn’t be so rewarding – so hard is good, but there’s a point when hard becomes bad and usually you’re the last one who figures out when that point has long since past. How do you know that what you’re doing is worth pushing through the pain for? There are three things that I use to take an objective look at a situation and decide whether to persist, or call it a learning experience:

R: Business is about people.
I’ve had a number of people tell me, “its not personal, its business”, normally while they’re in the process of screwing you and want to feel better about it. Business is all about people. The people you work for. The people who work for you. The people you sell to. The people you buy from. These people are your stakeholders and as soon as its no longer about them, then its time to move on.

P: Know what your niche is and why it matters.
This is about two things: (1) what’s your elevator pitch? (2) So what?

Your elevator pitch is not about your ability to explain your product to someone within 30 seconds. Its about that person catching your vision within 30 seconds and going away and explaining your vision to other people, who explain it to other people etc.

This comes back to your vision. Why are you doing what you do? Is it your vision, or someone elses? Do you believe in the vision? Is it worth the pain? Does anyone care about it other than you?

J: Have fun
One necessary ingredient of hi-growth businesses is stress – you don’t get growth without stretching your existing capabilities – but there is good stress and bad stress – just like there’s good pain and bad pain. Good pain is when you’re running hard. Bad pain is when you sprain your ankle. To keep going through good pain is beneficial and gives you good rewards. To keep running through bad pain is just stupid and does more damage.

The same applies for problems. You will always have issues and problems – make sure the majority are good problems, not bad problems. For example – making source code maintainability a priority from day one means that down the track, you can focus your efforts on solving business problems – not on bug hunting and regression testing. When the majority of your problems are bad problems, then it stops being fun and its time to fix the big picture.


What comes before vision?

13 February 2007

Too many people think that a company’s vision is just marketing talk and for some companies, that’s probably all it is, but for startup companies and entreupreneurs – it couldn’t be more important.

To understand vision – its useful to think about what comes before vision. What is it that you can’t stand? What gets at you so bad, that you just have to do something about it? The answer for most software Entreupreneurs is probably some sort of dis-satisfaction, whether it be because you can’t find the right tools, or the tools out there just don’t cut it, or … Its often this that leads an Entrepreneur to start a company and invest huge amounts of energy and money into it. There comes a point in time where the dis-satisfaction becomes so strong that you enter some super-human state of mind and realise you can do it better than anyone else and that its worth selling your house for and investing all your time for the next x years into and this becomes your vision.

Vision isn’t something that the whole company thinks up at the annual team-building day. It doesn’t come from the marketing dept or a mentor or the board of directors. It comes from leaders. Leaders who have vision will always attract people who want to follow and work for them because “without vision, the people perish”.

Vision is something that a lot of people write off because they don’t understand it. It is simply why we get passionate and committed to do what we do. If we’re working for a small software company and building a state of the art software system but no-body knows why … then what’s the point? You work for the leader because they’re the one with the vision.

I think that when it comes to writing a business plan for a software company, you should start with:

Vision - why are you doing it? This is driven by the dis-satisfaction that led you to start the company and is what gives you passion and commitment.

Mission – what are you going to do to fulfill your vision?

Strategy – how are you going to deliver on your mission?

Objectives – divide and conquer – how much of your strategy can you achieve this year?

Goals – things you can touch and feel and that when met will fulfill your objectives

Entrepreneurs who want people to follow and commit to them have to be leaders and this means knowing your vision and making it absolutely clear to everyone involved.