I’ve organised all of my software/business posts by the software lifecycle:
http://blog.butel.co.nz/software-lifecycle/
Yes, I’m a unified kind of guy – I find that you can’t build good software iteratively without having visibilty of the big picture – especially if you asipe to be agile.
Leave a Comment » | 
Software | 
Permalink
Posted by Andrew
Wigley Law have a really good article on IP ownership of software in New Zealand. The article is specific to New Zealand, but while the copyright law may be different in other countries, the concepts are similar. If in doubt, talk to your lawyer … this is not legal advice!
The default position of the law (in New Zealand) is that whoever commissions a software project is the owner, unless explicitly agreed otherwise. Commissioned is a term that’s been defined by case law to include systems that are based substantially on the client’s confidential information & processes. This means that the copyright law favours the client for any software that is based on the requirements of the client, even if the developer initiated and paid for the majority of the project.
What does ‘ownership’ actually mean with software anyway, when it can be copied unlimited times and ‘owned’ by multiple people? Ownership is a bundle of rights, all of which by default belong to the copyright holder. The rights are:
When a software project is developed for a client, then there is often less value than expected in owning the IP. As the diagram from the article shows, the code developed specifically for the project is often only a small part of the overall codebase, so the client will need licenses of the remaining code in order to use the source code.
For the developer, owning the IP carries responsibilities they may not want. From my experience, developing a software project for a client and keeping ownership of the IP can effectively make the software a product. Your client has purchased a license from you and their expectations are as if they’ve bought shrink-wrapped software. They expect you to support and maintain it and the quality of the product is your problem because you own it. This is fine if you are selling the software to numerous customers, but maintaining a product for one customer can be a lose-lose situation for everyone.
If you’re going to charge a one-off price to develop software for a client, then it may be best for the client to own the IP (and have licenses of any library code). If you’re worried about losing future work, then you can structure the contract with a first right of refusal on any future development with agreeable terms.
Part of the signoff on software projects (for external clients) should to be agree on the ownership of the IP by following three steps:
For more info – email Stuart from Wigley Law.
Leave a Comment » | Business, Software | Permalink
Posted by Andrew
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:
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.
4 Comments | Business, Software, Vision | Permalink
Posted by Andrew
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.
Leave a Comment » | Business, Vision | Permalink
Posted by Andrew
Hard Wired have launched a beta site (www.myhardwired.co.nz) providing their personal profiling system for free.
I’ve seen Hard Wired profiles on about 20 employees, friends and family members and they’ve all been incredibly accurate. Its based on 81 questions where you choose one option over another and it gives a profile that covers:
In each of these areas, you’re rated out of 10 for:
These give some pretty interesting combinations, like green/red = left brained, red/yellow = extroverted, red/blue = entrupreneurs, etc.
I am red/blue, with a bit of green under pressure. The combinations can be hard to understand, but there are some spot-on explanations, like this:
“Well Andrew, you’re one of those independent, self-reliant people who really enjoys a good project, especially if it’s creating something new. Turning your ideas into action can be highly rewarding. You’ll probably find that once you’ve finished a project, you automatically look for a new one. You may even find yourself looking for a new project as soon as you can visualize the end of the first one! Once you finish something, you probably get bored if you have to say behind and just maintain things. Where’s the fun in that?”
Once you’ve profiled yourself, it can be quite interesting to match your profile to your work-mates or partner to see how you can improve communication or to understand when to keep your mouth shut.
Leave a Comment » | Business, NZ Companies, Technology | Permalink
Posted by Andrew
You are currently browsing the Business Savvy Software blog archives for August, 2007.
