Originally Posted by Hiro
RIMs use of the term pre-beta is a late to the game attempt to cover up the faux pas. You don't ever pass around alpha prototypes to expected end-use customers for their own use and business process testing. Ever. RIM admits in the press release that PlayBook units are in the wild outside their walls. Either they are betas which aren't up to snuff, or RIM is even dumber an engineering outfit than I ever imagined by letting alpha hardware out into the wild.
Yeah, what does alpha or beta mean anymore?
Then what is pre-alpha or pre-beta?
Is there a post-alpha or a post-beta?
Which comes first pre-beta or post-alpha?
Is there any checklist of things that must be completed to qualify a product to have attained any of these stages of completion?
Can we build a timeline that shows how a product progresses through these stages of development.
Back in the 1950s they developed a planning discipline called PERT * (Program Evaluation and Review Technique) to plan and manage complex projects.http://en.wikipedia.org/wiki/Program...view_Technique
* PERT was later supplanted with enhanced techniques like POP (Piss On PERT).
PERT used a diagramming concept to layout milestones (like project start, alpha, beta, project completion) and the tasks (dependencies) that needed to be accomplished to reach those milestones.
Each task definition showed the estimated time and manpower required to perform the task.
The longest (duration) path of sequential tasks to reach a milestone defines the time required to attain that milestone.
If a project is behind schedule, it is easy to determine where the delays are, the resources needed (if available) to bring the task back on schedule, or the length of time the following milestones (including project completion) will be delayed.
PERT diagramming is a simple, but iterative process -- as the project progresses you learn things, continually revise the diagram, and the project schedule.
There are computer programs that evaluate the tasks and dependencies, apply calendar time, and calculate when the project (and milestones) will be completed.
The circled numbers represent milestones, e.g,:
10 - start of project
30 - alpha complete
40 - beta complete
50 - product Release
for a simple project
The arrows, Red Uppercase Letters (or starting and ending milestone nodes)) indicate tasks that must be completed, e.g.:
A (10-30) - Perform Alpha Development
D (30-40) - Perform Beta Development
F (40-50) - Manufacture Product
E (30-50) - Prepare Documentation
B (10-20) - Prepare Announcement and Promotional Material including co-muzzles
C (20-50) - Announce Product
We see a estimated time duration for each task, Gray Lowercase letters.
By calculating the duration to traverse each path through the diagram, we can calculate the longest paths (the critical paths) to project completion. This also identifies those tasks that cannot be delayed without delaying the project -- as well as tasks that can be performed concurrently.
Obviously this is an overly simplistic PERT or CPM (Critical Path Method) chart -- but it's a start.
We can take a general task like A (10-30) - Perform Alpha Development
and break it into many smaller tasks: define requirements, determine development costs, prepare cost benefit analysis, determine personnel requirements, etc.
If necessary or beneficial (it usually is) we can prepare a PERT/CPM chart for these smaller tasks that comprise the general task -- showing critical and concurrent tasks.
Everything we do to refine the diagram makes it more accurate and more representative of the project to be accomplished.
All this information can entered into a computer which will calculate dependencies, identify critical paths/tasks, etc.
As tasks are completed, the chart and computer model are updated and, based on the accuracy of prediction of completed tasks (planned vs actual time) a "degree of confidence" can be calculated for reaching each remaining milestone.
In the early 1970s I worked for IBM in Software Development for the Distribution Industries in Des Plaines, IL. We were waiting to get approval on a project to begin Beta development (writing the code, in our project). After weeks of frustration trying to get the various high(er)-level approvals, the Department Manager gave me a challenge:
Assume we want to develop a program with:
-- 1 line of code
-- 1 page of documentation
and, it's already done!
How long will it take to get it through the approval process.
After about 2 weeks on the phone, I had gathered enough information to create a PERT chart and entered the information into an APL PERT program...
It would take 12 months to get through the approval process -- for example, it had to go through Pricing and Forecasting (a two week process) two separate times -- and each process had to be scheduled at least 1 week in advance.
So, then, the Department Manager asked me to see what could be done to expedite
the process, e.g. things like only one pass through Pricing and Forecasting.
Another two weeks, or so, and I had a revised chart and a revised estimate.
Expediting the project added 1 week to the process -- it took 3 weeks to schedule executive (Armonk) approval to bypass the 2-week Pricing and Forecasting process...
This led to the following:In business, to do nothing, takes 12 months!
-The Des Plaines Doctrine-Expediting, takes a little longer!
-The Armonk Axiom-
I suspect that CPM scheduling and the like have been supplanted, over the years with more accurate project/program management and review techniques.
I suspect QNX (RIM?) needs to participate in something like the above to fulfill its contract to provide software for the moon rover and other Mil-Spec projects.
It is kind of sad, really, that the management at RIM, apparently, can't use available techniques to successfully define, manage and execute a "relatively" simple project of building a tablet -- this ain't exactly moon rover science!
However, it speaks volumes about RIM.
To be fair, things can't always be scheduled accurately -- or sometimes the stars won't align to make things happen as we wish.
I can remember a press invitation for an announcement meeting in Cupertino.
Once everyone was in place, Steve gave out some performance statistics and then made 2 product announcements:
-- the iPod HiFi
-- a leather case for the iPod
Obviously, they had planned to announce other products -- but they weren't ready...
...At least Steve had the sense to say nothing!