Great story, thanks for posting. Please mod anon. parent up.
I can support everything you wrote as I recently used this technique in a project that was late but management wasn't hearing what people were saying. Within three days of color-coded status implementation, three levels of management had readjusted their expectations (not calmly, but they did adjust).
Can't over-stress the need for non-political and simple design. Real-time is the magic that makes everyone turn to such a system for "true" status.
My implementation was web pages with style sheets to remove the Mozilla scrollbars. Soon after this status became available on the wall, managers asked if they could have access to the web pages from their desk.
This was the first time in my ten year career that I saw developers (myself included) become so invested in entering accurate task/test/schedule tracking data. It was open, peer reviewed and non-political. And when you took some action that would change the status (added new task, closed a ticket, changed an estimate), you immediately looked to the rollup status page to see the impact on the overall project schedule, as well as the drill-down for your individual status.
Agree, if we differentiate ad-hoc requirement discovery from ad-hoc requirement implementation.
Google, Linux, Yahoo all appear to have flexible architectures and motivated architects, who integrated new requirements into the existing system without creating a house of cards.
Did the customer see an early prototype or previous incarnation of the system before signing the initial contract?
If the first prototype seen by the customer occurs after negotiation of scope, the scenario you outline is almost unavoidable (unless the product/market is well defined by existing products, in which case a custom solution probably wouldn't be on the table).
Fork the spec for query building into two sections.
One where real requirements analysis yields the top ten most valuable and requested queries + report templates. This can be handed off to a designer who creates an efficient and highly usable interface.
The second spec is for a generic ad-hoc query and reporting mechanism. Since the need is so very generic and so very unpredictable, prudent analysis concludes that a buy solution would be more practical than a build solution. Therefore, buy a generic reporting solution like Crystal Reports to meet the generic needs of the generic spec.
Finally, create separate cost, development and user feedback tracking for the two reporting subsystems. Review at 3-month intervals.
The winner will be clear sooner rather than later.
When you have collected enough data on such defects, have a script total the impact every minute and update a status web page available on the intranet and on a wall-mounted status monitor, where you report other defects. It takes a bit of political design to make this work properly (judicious use of color and anonymity), but it can bring everyone around to taking responsibility for schedule changes. The key is unemotional data collection and reporting.
you are unlikely to have the tracking data needed to justify your proposal (e.g. stopping/slowing changes).
You need to collect tracking data (task estimated effort and actual effort, linked to change requests) before there is a visible impact on the schedule.
One result of ad-hoc software design and implementation has been government regulation of software in the financial, security and pharmaceutical sectors.
One result of government regulation has been the emergence of requirements management tools like Borland's CaliberRM and Telelogic's DOORS.
These tools trace every functional requirement back to a business requirement. They also track the risk (schedule, safety, robustness, performance) of every functional requirement to the rest of the system.
Vague specification, like vague design is an indicator of not understanding the problem. The first step towards understanding the problem is categorization of ignorance, such as unexpected consequences already experienced by the project.
Good requirements management tools incorporate practices that have been proven to flush out vague specifications. Good traceability educates upstream participants so they can produce better specs in the future. Better specs yield better products, including better spec management tools
If you have an automated QA process and a decent release management system that generate tracking data, you can create "dashboard" status displays on wall-mounted monitors that show everything you listed. Although this may seem draconian, it actually brings management into the schedule as an early risk management participant, rather than an outside observer who offers little input into daily tactics.
Non-minor setbacks are often the result of aggressive scheduling, but cannot always be attributed directly to the specific change or person who initiated the change.
Look at a schedule as just one component of a (good or bad or in absentia) process. Look at a process as just one component of the product. Then non-vetted schedule changes (aggression without responsibility) become product defects.
What do you do with defects? You track them. You test for them. You fix them. Data (evidence) is needed for tracking, testing and fixing schedule defects. Collect the data in advance so you can fix the schedule in retrospect.
Release managers can track requirement changes and their impact (effort, schedule) on the project. These changes can be reported separately from the primary schedule, so that everyone can see the impact of scope changes.
Change is not bad. Adapting to environmental changes (competition, customer education by early prototypes, vendor roadmaps) can make the difference between a one-shot failed project and a multi-generation successful product.
Big Visible Charts is a time-tested technique for non-political status reporting that helps everyone (from senior management to QA) take responsibility for the global impact of local changes. Grab a few unused monitors and create a wall-mounted status display with 1-minute project status updates, you'll be amazed at the results.
mychitchat.com for PIN-less prepaid dialing with good voice quality and no gimmicks, affordable but not rock bottom cheap. Good for cellphone use. Absence of PIN can save a lot of time when re-dialing countries with poor connectivity.
uniontelecard.com for calling cards close to rock bottom cheap with a minimum of gimmicks, but maintenance fees guarantee that ununused minutes will soon disappear. Voice quality ok, not great, typical for calling cards.
And the ILEC's today cumulatively have more power than AT&T ever did, extending beyond POTS into cellular and broadband. All made possible by cash flow from their POTS monopoly.
> Standard Oil's monopoly was dismembered.
But the dismembered portions were all owned by the same people who owned Standard Oil. What's more, the dismembered portions together made more money that the original Standard Oil.
Talked to the pilots' union at Delta recently? How about United Airlines? Their pensions are not looking too good -- coming soon to a union near you.
> The weekend was created.
Are you classified as a salaried technology professional? Then your hours do not qualify for overtime. In fact, they may not qualify for time, depending on your employer.
Americans in unions are very interested in excercising their political power, what's left of it. But don't stay up late waiting for your 401K to lobby Washington for your children's future.
Once a business demonstrates sufficient long-term viability, there is inevitable pressure to consolidate and "standardize" the market by the removal of small competitors.
The most politically attractive tool for removing small vendors from a market is overwhelming economic force (free as in beer). Current case in point, Gmail will destroy small ISPs by teaching users to demand hundreds of megabytes of email storage. Yahoo & Hotmail have already responded.
Indemnification will do the same for Linux distributions. You may be able to roll your own distro, but it will be increasingly difficult to distribute it without legal exposure (not only to the publisher, but the distribution channel, e.g. SourceForge/OSDN).
After economic consolidation comes political consolidation (regulation). Sender-pays email, state-issued ID for publication, bank-issued ID for consumption, firewall liability insurance in exchange for permission to face the public network, VOIP-driven consolidate of "offline" and "online" IDs -- and just when you're about to go insane with boundary barriers: premium green-light services that guarantee swift passage to those who can afford it.
Creative anarchy will remain possible within organized economic pools that can negotiate regulatory barriers to entry and evolution.
Bundle the credential chain for your private cert (i.e. root cert and optional 'intermediate roots') into a PKCS7 file. Distribute file on a Verisign/Thawte authenticated page. Single-click will install the root cert in most browsers.
Your primary root cert can keep a long (decades) lifetime while your server certs can have a short (months) lifetime. Safest is to use intermediate roots (years lifetime) which can be revoked at will (in case of private key compromise) via live CRL on the primary root.
Slashdot Mirror
Great story, thanks for posting. Please mod anon. parent up.
I can support everything you wrote as I recently used this technique in a project that was late but management wasn't hearing what people were saying. Within three days of color-coded status implementation, three levels of management had readjusted their expectations (not calmly, but they did adjust).
Can't over-stress the need for non-political and simple design. Real-time is the magic that makes everyone turn to such a system for "true" status.
My implementation was web pages with style sheets to remove the Mozilla scrollbars. Soon after this status became available on the wall, managers asked if they could have access to the web pages from their desk.
This was the first time in my ten year career that I saw developers (myself included) become so invested in entering accurate task/test/schedule tracking data. It was open, peer reviewed and non-political. And when you took some action that would change the status (added new task, closed a ticket, changed an estimate), you immediately looked to the rollup status page to see the impact on the overall project schedule, as well as the drill-down for your individual status.
Advise all to re-read parent and take notes.
Nice and simple.
Did the QA traffic light change any behavior in the project (developers, testers, managers)?
Couldn't agree more, but non-specific specs deserve non-specific solutions.
Rapid Prototyping.
Throw in "All Prototypes are Finished Applications" and you have the beginning of a beautiful product.
Agree, if we differentiate ad-hoc requirement discovery from ad-hoc requirement implementation.
Google, Linux, Yahoo all appear to have flexible architectures and motivated architects, who integrated new requirements into the existing system without creating a house of cards.
Did the customer see an early prototype or previous incarnation of the system before signing the initial contract?
If the first prototype seen by the customer occurs after negotiation of scope, the scenario you outline is almost unavoidable (unless the product/market is well defined by existing products, in which case a custom solution probably wouldn't be on the table).
Fork the spec for query building into two sections.
One where real requirements analysis yields the top ten most valuable and requested queries + report templates. This can be handed off to a designer who creates an efficient and highly usable interface.
The second spec is for a generic ad-hoc query and reporting mechanism. Since the need is so very generic and so very unpredictable, prudent analysis concludes that a buy solution would be more practical than a build solution. Therefore, buy a generic reporting solution like Crystal Reports to meet the generic needs of the generic spec.
Finally, create separate cost, development and user feedback tracking for the two reporting subsystems. Review at 3-month intervals.
The winner will be clear sooner rather than later.
When you have collected enough data on such defects, have a script total the impact every minute and update a status web page available on the intranet and on a wall-mounted status monitor, where you report other defects. It takes a bit of political design to make this work properly (judicious use of color and anonymity), but it can bring everyone around to taking responsibility for schedule changes. The key is unemotional data collection and reporting.
you are unlikely to have the tracking data needed to justify your proposal (e.g. stopping/slowing changes).
You need to collect tracking data (task estimated effort and actual effort, linked to change requests) before there is a visible impact on the schedule.
Think of it as defensive data collection.
One result of ad-hoc software design and implementation has been government regulation of software in the financial, security and pharmaceutical sectors.
One result of government regulation has been the emergence of requirements management tools like Borland's CaliberRM and Telelogic's DOORS.
These tools trace every functional requirement back to a business requirement. They also track the risk (schedule, safety, robustness, performance) of every functional requirement to the rest of the system.
Vague specification, like vague design is an indicator of not understanding the problem. The first step towards understanding the problem is categorization of ignorance, such as unexpected consequences already experienced by the project.
Good requirements management tools incorporate practices that have been proven to flush out vague specifications. Good traceability educates upstream participants so they can produce better specs in the future. Better specs yield better products, including better spec management tools
If you have an automated QA process and a decent release management system that generate tracking data, you can create "dashboard" status displays on wall-mounted monitors that show everything you listed. Although this may seem draconian, it actually brings management into the schedule as an early risk management participant, rather than an outside observer who offers little input into daily tactics.
Non-minor setbacks are often the result of aggressive scheduling, but cannot always be attributed directly to the specific change or person who initiated the change.
Look at a schedule as just one component of a (good or bad or in absentia) process. Look at a process as just one component of the product. Then non-vetted schedule changes (aggression without responsibility) become product defects.
What do you do with defects? You track them. You test for them. You fix them. Data (evidence) is needed for tracking, testing and fixing schedule defects. Collect the data in advance so you can fix the schedule in retrospect.
Otherwise, every day will be Groundhog Day.
can be used as an excuse to avoid process, which is a distinct animal from bureaucracy.
Good process is independent of the intelligence of the humans implementing the process.
Good process amplifies the effectiveness of all participants.
Good process generates tracking data that can be used in negotiations between development (reality) and management (theory).
is at least as important as managing down.
Release managers can track requirement changes and their impact (effort, schedule) on the project. These changes can be reported separately from the primary schedule, so that everyone can see the impact of scope changes.
Change is not bad. Adapting to environmental changes (competition, customer education by early prototypes, vendor roadmaps) can make the difference between a one-shot failed project and a multi-generation successful product.
Big Visible Charts is a time-tested technique for non-political status reporting that helps everyone (from senior management to QA) take responsibility for the global impact of local changes. Grab a few unused monitors and create a wall-mounted status display with 1-minute project status updates, you'll be amazed at the results.
Now there's a useful term to come out of this discussion. Thanks!
In the absence of strong identity verification for "voting" systems that presume to measure "popularity", all metadata matures to spam.
mychitchat.com for PIN-less prepaid dialing with good voice quality and no gimmicks, affordable but not rock bottom cheap. Good for cellphone use. Absence of PIN can save a lot of time when re-dialing countries with poor connectivity.
uniontelecard.com for calling cards close to rock bottom cheap with a minimum of gimmicks, but maintenance fees guarantee that ununused minutes will soon disappear. Voice quality ok, not great, typical for calling cards.
> AT&T's monopoly was dismembered.
And the ILEC's today cumulatively have more power than AT&T ever did, extending beyond POTS into cellular and broadband. All made possible by cash flow from their POTS monopoly.
> Standard Oil's monopoly was dismembered.
But the dismembered portions were all owned by the same people who owned Standard Oil. What's more, the dismembered portions together made more money that the original Standard Oil.
Identity decentralization != Financial decentralization.
> Labor unions were established.
Talked to the pilots' union at Delta recently? How about United Airlines? Their pensions are not looking too good -- coming soon to a union near you.
> The weekend was created.
Are you classified as a salaried technology professional? Then your hours do not qualify for overtime. In fact, they may not qualify for time, depending on your employer.
Americans in unions are very interested in excercising their political power, what's left of it. But don't stay up late waiting for your 401K to lobby Washington for your children's future.
Pollix, a Knoppix (Debian live linux CD) derivative with Java development tools like Eclipse, Netbeans, BlueJ, JGrasp, JSwat.
See also 300+ open-source Java components.
Once a business demonstrates sufficient long-term viability, there is inevitable pressure to consolidate and "standardize" the market by the removal of small competitors.
The most politically attractive tool for removing small vendors from a market is overwhelming economic force (free as in beer). Current case in point, Gmail will destroy small ISPs by teaching users to demand hundreds of megabytes of email storage. Yahoo & Hotmail have already responded.
Indemnification will do the same for Linux distributions. You may be able to roll your own distro, but it will be increasingly difficult to distribute it without legal exposure (not only to the publisher, but the distribution channel, e.g. SourceForge/OSDN).
After economic consolidation comes political consolidation (regulation). Sender-pays email, state-issued ID for publication, bank-issued ID for consumption, firewall liability insurance in exchange for permission to face the public network, VOIP-driven consolidate of "offline" and "online" IDs -- and just when you're about to go insane with boundary barriers: premium green-light services that guarantee swift passage to those who can afford it.
Creative anarchy will remain possible within organized economic pools that can negotiate regulatory barriers to entry and evolution.
Certificate Enrollment Control.
Bundle the credential chain for your private cert (i.e. root cert and optional 'intermediate roots') into a PKCS7 file. Distribute file on a Verisign/Thawte authenticated page. Single-click will install the root cert in most browsers.
Your primary root cert can keep a long (decades) lifetime while your server certs can have a short (months) lifetime. Safest is to use intermediate roots (years lifetime) which can be revoked at will (in case of private key compromise) via live CRL on the primary root.
Sample code for Multi-level CA.
Power Schmoozing: Tips and Book.