Architecture Development Cycle

>Set context in terms of stakeholders and their needs
| Build buy-in for the process and what you want to achieve
| Propose Actions
| Esablish Ingrastructure
| Characterize current and desired state (vision, goals, needs, requirements)
| Develop recommendations, tailor actions, cement buyin,
| Establish prioorities
| Develop approach, gain buyin
| Plan actions
| Creat architecture
| Test and validate
| Refine (next cycle?)
| Deliver
| Analyze & validate results -
|____________________|

Project Plan Development Process Steps

1. List tasks and hierarchically subdivide down to 5 day lengths
Team
>Task Areas 1...n (remember the span of control rule of 7)
>>Task Area 1 Subtasks 1...n (remember the span of control rule of 7)
>>>Subtask 1 Tasks (in 5 day increments)
>>>>Objective or milestone acheived at end of each Subtask

2. Link tasks bia the predecessor/succcesor fields (assumes your working in MS Project)

3. Resource tasks via the Resource Dialoge
-Resources should not be human names, but should be the "role" of the person working on the task (e.g. Technical Analyst, Systems Engineer, PM, etc).
-Add the percentage of that resource that will be employed against the task (e.g. 2 full time analysts would be 200% of an analyst resource)
-Input the duration of the task "in days" via the same dialogue, not via the project plan view.

*Doing it this way forces MS Project to calculate the tasks duration in hours. DO NOT put the task duration into project via the project plan view. This hardcodes the duration and can decrease the flexibility with which the plan may be updated or incorporated into other plans.

4. Look at the "Task Usage View". This provides a weekly roll up of hours expended in labor. That summary should be level across all weeks if you expect the staffing levels to stay steady. If it is necessary to increase or decrease hours to achieve a steady "burn rate" you can look into the tasks below each weekly roll up and tweak the hours of individual resources that are working on a given subtask. This is also the same method you would employ to avoid overloading a resource type with too many hours of labor per week.

Shovel Eater progress report - 11 FEB 2005

It was a cold and very windy weekend in Germany Valley. On Saturday morning Rick Orben, Susan Posey and I left breakfast at the Gateway restaurant to gear up and drive into the woods surrounding Shovel Eater cave. In rapid fashion we quickly had the generator running and the powercords stretched. While I took the hammer drill to the dig face, Susan and Rick got started with the haul pan and moved gravel through the upper passages. A vaste pile of rubble was left from our previous trip into the cave and it was high time to get it out of the way.

The chisel mode of the hammer drill works wonders on fractured rock. Within minutes I had several buckets of rock laying in the crawl before me. My latest acquisition, a small rake from Lowes, allowed me to drag the gravel up the crawl from below my feet and to the pan positioned above my head. Handfuls of gravel loaded into the pan would be pulled out of the crawl by Susan, then hauled up the pit in two and a half gallon buckets by Rick. He dumped them into the floor of the upper passage and replaced the pile the he and Susan had reduced when the first entered the cave that morning.

This tedious means of prying rock from the walls of our dig and passing it back 50 or more feet to the entrance area has gone on almost monthly for the last 16 months. And it may soon come to an end. By the end of the day we were all worn out, but the breezy lead looked even better leaving than it did when we arrived. Previously we could only see in to a crevice that appeared four feet high and six inches wide. Now we could actually touch it.

As we left for a rendez vous over dinner with other cavers the dig face lay fractured and piled in loose rubble. But just beyond the wedged boulders we can see into a meandering passage, obviously vadose in origin. It's four feet high by eight inches wide and takes an immediate sharp bend to the right. The floor is obscured by gravel now but it was headed to the right through an undercut anyway. And for the first time we're beginning to get back a respectable echo for our bork.

This has us thinking that an adhoc return trip may be in the offering.

Day 4,

Oh hell. We don't have a B&P numjber yet because this opportunity still hasn't been vetted as worthwhile by the business unit. They're going to scrutinize this at our Gold Team Review, scheduled for today at 2 p.m.

things to look at:
make sure you have a complete outline of activities to perform during the prop development
sign up responsible persons asap
scan rfp and identify the value/deliverable/schedule questions early

Worked on getting graphics and content together for todays gold team review
Turns out one of our subs has a major weakness. They've got no M&S experience, just lots of hands on with this particular technology. We're scrambling to find some inhouse qualification in M&S that will fill the gap. Failing that we may not even be able to complete the past performance requirements in this area.

Proposal Development Diary - Day 3

Prepare for the Gold Team Review
Downloaded and reviewed the Gold Team preparation slides, realized we are way behind on developing story boards.


Work on Storyboards
- reviewed story board training slides
- compared short outline to what was on the wall, found that only Volume A was up, not B, C, or D
- parsed RDO into multiple pages for Volume B, C was put up by proposal manager, no input back yet on volume D (pricing), looked at D but nothing to really parse, it's just a lot of procing guidance that we must be incompliance with. Will refer to compliance matrix tovalidate.

Work on Quals - going to give this to proposal center.
Track status of Cost Prop
Track status of B&P number - sent an email to the boss but no response yet. Still waiting for one signature.

Proposal Manager is writing SOW's for the two subs. He already developed a staffing estimate with their input.

1. Compliance - Gold Team Review will cover all the RFP Require'd areas

2. Completeness - Do the storyboards, indicate they will cover each of the requirements items in section L, and/or cover the paragraph requirements in general for the Required PWS/WBS/SOW/SOO numbered paragraphs.

3. Themes - Do the section themes define what we want the customer to take away from the section?

4. Technical Approach - Do the strategy/approach make sense for this section?

5. Identify any holes or concerns.

Check out (phase 4. Gold Team Review)

Proposal Development Diary

Methodology
RDO -> Writing Assignments -> Page Counts -> Win Themes ->
Solution Strategy -> Writing activities
Volume C,L,M review for missed requirements.

Comments:
Notional schedule can be based on the CLIN list.
180 days on the cover sheet? September 2005 deadline.

Day 1 - Feb 7th, 2005
Arrived in Proposal Center, received a hardcopy of the "Requirements Driven Outline" that the prop center had created. This purportedly takes section C, L, & M of the customer's RFP and massages them together into an outline that can be used for developing a "compliant" set of proposals (Tech, Cost, Mgmt). See http://www.captureplanning.com/articles/11133.cfm for more about the RFP sections.

Went through the RDO and found it to be very repetative. Not sure why. At the end there is a useful section that combines L&M based requirements into an outline that you could add writer assignments to and base your proposal development effort upon. This is what's happening now. Various sub's and partners have staked out the sections they wish to write against and have begun scribbling.

One sub seemed consternated that the Prop Mgr did not actively allocate or idenitify writing assignments (I was somewhat mistified by that lack of performance as well). Eventually the sub put a stake in the ground and said "I will write this part" (basically an entire volume that covered half of the technical problem set.

Next, the same sub led a small exercise to establish page counts for his section. We knew that his volume was limited to 50 pages so we walked through the sections of his volume (based on the RDO) and assigned pages to various elements in the outline. Curiously this RFP includes things like experience and management capability within the technical volume, so those received a couple of pages. After going through the exercise we were able to conserv about 21 pages of the 50 for use in the technical solution area.

In the RDO I noticed a dearth of information that might have come from Section C of the RFP. I went back to look at that section (which should normally be a statement of work) and found a 130 page section that basically describes the environment and mission of the customer, how they work, their basic schedule of activities, etc. I assume this information is provided to give the bidder a common understanding of what kind of environment they will be expected to maneuver within. This also helps take risk off the offerers shoulder, "he told us what to expect".

There is no management volume here. It's sprinkled into the Volume A and Volume B technical problems. Must pay close attention to ensure that some representation of a managed project appears in this proposal.

I'm still in the process of reading through Section C and looking for real requirements that might actually have to be addressed in the RFP (I feel like this is an important role that I can play, even though it hasn't been designated as my job. Frankly I'm not to sure about what my role is here besides "look for similarities and comparisons", across the technical solutions I suppose. But one of the things I want to do is make sure we're covering all the bases and can provide a technically compliant proposal). As I go through section C in soft copy I try to highlight requirements and tie them to the volume in which they should be addressed. I need to build a checklist to ensure these are all covered in the proposal writing later on.

Day 2
I came in this morning to find "Win Strategies" (or win themes) up on the board. They are as follows:

1 - Team with Partner T.. for customer knowledge and the solution they have in hand for Volume B.

2 - Team with Partner I.. because they have tomorrow's solution and can meet or exceed an aggressive development schedule. Also today's solution can naturally expand to solve tomorrows problems (all refering to Volume A).

3 - Offer clost, best-suited development center (not really a strong strategy unless it can save a lot of travel dollars).

4 - Provide "advanced degreed" expertise to solve customer's technical challenges. (Inside scopp has it that the customer loves PhD's. Gives hims somewhere to point the finger?).

5 - Advertise our vast experience in many project of similar nature.

6 - We will employ a communications module that ties together and integrates the seperate problems of Volume A & B and improves the communications model.

7 - Provide a funtional, plug-in capability ability. Key to availability requirement. Will further develop this baseline functionality but gets them up and running fast.

Sections L&M were parsed and integrated into an RDO by the prop center, but they ignored section C of the RFP. Section C is supposed to be a Statement Of Work but in this case it's not much of one. Instead it's more of a requirements specification. Those requirements should have been integrated into the RDO, but weren't. As a result I put all the content of the section C word document into a word table and then copied that into an excel spreadsheet. It's rough but atleast we have a compliance matrix of sorts that we can review and check out work against.

We have a gold team review on Friday. Need to look at the gold team review slide templates and start populating them.

V. put together this outline for the Volume A technical approach...

4.0 Technical Approach
4.1 Approach to simulate M.....
4.1.1 Introduction
4.1.2 Network Scnario
4.1.2.1 Increment 1 - We provide the capability to ... (verbatim from the proposal)
technical approach
-layout overall approach
-take a use-case and explain approach
-provide an example of previous effort where a similar task has been done
-identify the deliverable and describe it
4.1.2.2 Increment 2
(same as above)
4.1.3 Assessment of network topology
4.1.4 Output data
4.1.5 Communication system/racks
4.1.6 Standalone mode
4.1.7 Interfaces
4.1.8 Physical Network Considerations