Entries For: May 2008
2008-05-30
On Managing Risks
Not identifying and managing risks in a project leads to problems and possible project failure. It is a critical part of iterative development process but also applies to projects in general. An iterative process helps you discover and evaluate risks so that high risk, high priority issues are dealt with during the early stages. Not dealing with them at an early stage, or revisited in an iterative manner leads to a multitude of problems.
There a few things you need dig out for risks:
- User Requirements
- Development time
- Resources (personnel and infrastructure)
User requirements
Are really important. One of the lessons learnt when I was a grasshopper (maybe still am), is that this needs to be dealt with continuously and you need to lead it. If there are any ambiguities, it needs to be cleared up. This needs to be done continuously at least on a weekly basis. Constant feedback is important, with priority on the major concerns.
Development and implementation time
For IT projects, I consider this a major risk, as it is the most expensive one and increase the risk for personnel resources. For IT the highest costs are skilled developer and engineer time. Anything the requires significant development time, is high risk. From experience development isn't a case of, let's put developer x for 5 days, and he will create 5 features. In 5 days, the first iteration, those 5 features are going result in the need for testing, result in new issues and an investment in particular code. User requirements become damn important here, as you need to make sure you're doing things so that the users can test early and provide feedback. Funcationality over gloss, is important at this stage.
Beyond that developers and engineers need to look at the technical risks and match it to user requirements. You'll need to test very early on, frameworks and components that you will be using. For example, if you're storing in an RDBMS.. does it have the features that allow you to deliver on the user requirements? These will need to be early testing focuses. As a real world example, one of Inigo's projects, the requirements was integration with different web applications or systems for user authentification which were undefined. "Undefined" means it's a high risk. So it was a testing focus way back and different authentification plugins was already evaluated and a difficult requirement was researched and communicated to the client. So when there was a suggestion to implement, we can be confident in delivering a quality solution, ahead of time. It's beyond the scope, but not beyond resources, which translates into a very happy client.
If it wasn't a testing focus, it would seem like it came out of the blue, and then developers would be pushed to implement something that their existing code base doesn't support near tight deadlines. Result? Possible delays, unanticipated problems, overtime, cutting back on something the client thought was an important requirement... well you know the drill, it's a common situation.
It can be avoided with proper processes that evaluate risks and sets the right priorities.
Resources
The previous risks also tie in to a major, major one.. human resources. None of the above matters then when you have nobody around or they are not productive. The risks are even higher if you count productiveness and quality of a good team, in addition to the acquired knowledge that may be lost. Look after your skilled staff, and have teams that overlap in skills.
Hardware, by comparison is an easy risk to manage. You just need to communicate to the client, the costs and risks clearly for this. Most clients just put in 99.9% uptime, but if you communicate with them the risks and downtime they are willing to tolerate, they may be thankful that the costs can be much lower by reducing it to say 95% uptime, and explain clearly that it will be up almost all the time, but if their is a hardware failure which is rare (once a year?), it may take up to 5 days before it is up again. People are happier when they understand the choices they have to make.
I blame football for this
I don't believe they're playing repeats of Champions League when the conference finals are on.
Back to the point, it's sad when basketball has this problem. It's an unwritten rule in basketball that you man up. If no foul is called, you play through it. If you're injured, you don't mention it. See Kobe playing with torn tendons in his finger and Manu who is probably on pain killers with a busted ankle. When there was an obvious foul on the last play of the Lakers-Spurs series, the coach of the losing side says, "You don't call that a foul in the Western Conference Finals". You shouldn't flop and cry about a foul like footballers, and then whinge about it some more in the press after the game calling for reviews and what not.
Hopefully the players themselves will keep things pure, and the floppers can try their luck in the Premier League or something. They shouldn't be in the NBA.
2008-05-25
Out and about setup complete
Finally got myself a Nike Mobile Case (flash!) , which wraps around your arm. This shortens the length between cord and earphones.
The Centro actually is a good music player. With Pocket Tunes upgrade (which I had from my TX), it plays all my media files including Ogg Vorbis. Only annoying part is that you need a bulky 3.5in adapter.
I put my Centro upside down in the case so that the headphone jack is at the top. The case stretches nicely to cover the adapter and also excess cord. Once adjusted, the cord length is very short, so there is almost no flapping due to movement. Matched with my MX55's this allows me to run and do stuff while listening to music. I'm going to have a go next weekend to see how well this setup holds up to a morning jog and shooting hoops which was the main reason to look for the headphones and case.
2008-05-21
Sharing Information on FOSS usage in Government
Working on projects at OSCC, provides access to a large amount of information regarding OSS adoption. Mechanisms are being put in place to get this information out in the open.
- http://knowledge.oscc.org.my/search?Subject%3Alist=OSCC
- http://knowledge.oscc.org.my/case-studies/malaysian-case-studies
Of note are the adoption charts and detailed breakdown of known implementations by all agencies federal and state.
2008-05-20
Pushing the envelope
A conditioning coach once showed a graph of continuous improvement through training. Then how much the drop is after a few days off compared to the slow and gradual improvement of continuous training. It takes a lot of effort to get back up. A few more days off and the effort and time looks almost insurmountable.
This theory however seems to apply to other areas also. My development environment has been neglected somewhat for a few months. It took some time to get a development environment going again this weekend for me. A lot of updates were needed and my skills degraded severely. So I have to be careful to avoid falling behind and to keep my developer skills current.
The work doesn't stop there though. Just as in sports you have to keep pushing the limit to improve yourself, and this is a slow, continuous process. Also try to continuously be better at everything not just career related. Be a better parent, better member of community etc. Otherwise when the years pass by quickly you'll find that it's all too late to start again.
