Project Management - you can't go into many directions at the same time

One of the most important things in managing your project is to have a clear vision on what is it you want to deliver. Of course we all want to deliver maximum features with very low defect ratios, within 6 months time frame. I have news for you this is usually not possible. Those are interdependent and usually investing in one of the constraints costs you neglecting another. You will be making priority decisions throughout the project, so why not to get clear on what are them at the beginning. That would also give your team a clarity on what is important to the project and how to act when they would have to make priority decision themselves. So keep everybody in sync by providing priorities in advance.

As it always come to comparing two (sometimes more) project characteristics when you are supposed to make a decision I would recommend to write down an order of priority list which has the most important characteristic on top and then descend to less important characteristics.

So for example if you are targeting visionaries with new innovative project you know that you have to generate a specific minimal features set, release it as soon as possible, and think about quality later. You can reflect it in your list. That means that if your defect levels are high but you still don't have complete feature set you will devote your time to implementing features and not improving quality. Second important thing is to define what are the must-haves from the list - things which have to be accomplished for the project to be successful.

Now, make sure you are on the same page with your sponsors and potential customers as otherwise you are heading for disaster. You must be sure that list reflects priorities of people who fund the project. Talk to the sponsors and get them to choose what's the most important by simply asking them. If they don't want to choose as they want 'perfect quality, full feature set, 6 months, 4 people team' ask questions which will mimic decision you will have to make: "let's say it's a month and we still don't have full feature set and quality is low, shall we focus on quality or on features? Or maybe delay the release?". Do whatever you can to get it out from your sponsor. If you can't make the decision yourself (in advance) and get sponsor to agree, sign off on it. Without that project will be dead on arrival - overconstrained projects rarely are harder to deliver they usually are impossible to deliver. Unless you are Chuck Norris of course.

How to develop software faster

Nice article on how to develop software faster: here

Project Management Tips - Value Your Time

Tip: start be aware of where you spend your and your team time. Spend it wisely.


Steps to get there:

1. Once you reach the office, sit and don't start your machine for 10 minutes. Just sit there. Be careful with that - you may panic first few days. It's important you do nothing these 10 minutes. During this time you can think on what you would like to accomplish this day. Now for the scary part - before you get your emails.

2. Imagine time as a physical resource (imagine unit representative). Every time you are planning to spend some of it imagine how much of units you need to take from the heap of all units you have to complete the project and ask yourself: is it worth it? If it is then go for it. If it's not forget about it.

If you want to call the whole team (8 people) 2 hours meeting to discuss which variant of user interface workflow for some scenario would be better think again. Be creative in finding ways to make this decision at lower cost than two man days. Toss a coin for example.

3. Don't write elaborate emails. They look nice, but you have to pay a lot of time to write them, and then your recipients pay time to read them. Straight to the point is a good approach. People know you are smart anyway.

4. Don't answer your emails. Or less extreme version don't answer your emails right away. If you don't - problems magically tend to resolve themselves even without your attention. Don't worry if they don't you will be reminded about them. Extra benefit here: you minimize the risk of becoming your company's google search replacement.

5. Make sure that you open your mail program only once, twice a day - every 4 hours or so. Spend time with it, caress it for an hour or so, and then close it and start doing a real work. Limit your time spent with it to an hour, two hours a day. With that in mind your mails will be much more efficient.

Software Defect Reduction Top 10 List

I've just found interesting article on statistics behind defect reduction by Barry Boehm and Victor Basili: here.

According to the article top ten defect reduction list is the following (I'm citing the article):

1. Finding and fixing a software problem
   after delivery is often 100 times more
   expensive than finding and fixing it during
   the requirements and design phase.


2. Current software projects spend about
   40 to 50 percent of their effort on avoidable
   rework.


3. About 80 percent of avoidable rework
   comes from 20 percent of the defects.


4. About 80 percent of the defects come
   from 20 percent of the modules, and
   about half the modules are defect free.


5. About 90 percent of the downtime
   comes from, at most, 10 percent of the
   defects.


6. Peer reviews catch 60 percent of the
   defects.


7. Perspective-based reviews catch 35
   percent more defects than nondirected
   reviews.


8. Disciplined personal practices can
   reduce defect introduction rates by up to
   75 percent.


9. All other things being equal, it costs 50
   percent more per source instruction to
   develop high-dependability software
   products than to develop low-dependability
   software products. However, the
   investment is more than worth it if the
   project involves significant operations
   and maintenance costs.


10. About 40 to 50 percent of user programs
    contain nontrivial defects.

Software Quality Definition Revisited - Domain Landscape

Happy Year 2009 to everybody.

As new is coming I decided to add something new - a bit more structured to the blog. I will try to describe my understanding on what is on software quality map and where it fits. I will be tagging this thread with 'software quality landscape' tag

As described in my post ealier (here) Following are the software quality characteristics:

External characteristics:

1. Correctness - does software do correctly what it is supposed to?


2. Usability - is software intuitive and easy to learn and operate?


3. Reliability - is software working correctly when fed with correct inputs/environment condititions?


4. Performance - is software working within acceptable resource limits/response times?


5. Security - is software immune to attacks, does it protect data fed to it?
   Robustness - how well software behaves when fed with incorrect inputs/environment conditions?


6. Scalability - will software behave correctly and efficiently when fed with significantly increased volume of data

Internal characteristics:

1. Maintainability - is software easy to maintain?


2. Reusability - are software parts easy to reuse when developing another software which needs similar functionalities?


3. Portability - how easy it is to port software to other environments to the ones for which it was developed?


4. Extendability - how easy it is to add new features?

I will discuss all those in greater detail in subsequent posts in this thread ('software quality landscape').