## MBARI Offsite
## Day 2: Strategic Planning
#
## Tue Mar 22, 2005

[mcgill] Instrumentation Strategic Planning

Intro [mcgill]:
group composition
instrument definition: [[sensor/actuator]power and data elect]->platform

goals
-trying to improve what MBARI engineering produces
-we should strive tangible results from this meeting

mbari mission statement: world center, development of better instruments, systems

-address immediate and long term instr needs of mbari scientists
-expand teh frontiers of marine sciences
-push tech to wider community

two recent developments in vehicle technology:
ezcatch: specific solution to specific problem

bose suspension: fundamental breakthrough
- sometimes need chicken catcher
- bose took 24 yrs to develop

planning process:
- determine goals
- assess environment
- map out plan to achieve goals

SWOT [roman]:
32 -> 4 in each SWOTs -> strategic imperatives
weaknesses:
too many projects
engineering connection to science
sometimes work on wrong things, and underestimate effort, resources

we reinvent the wheel

opportunities:
establish expertise in 2-3  key technologies
collaborate with outside groups
shifting local and nat'l priorities create demand for innovative instrumentation

Threats:
science may choose not to collaborate
mgmt may not support our roadmap
instruments may be developed faster, cheaper elsewhere 
growing env and security concerns may limit tech we can deploy

strategic imperatives:
involve operations
end and exit strategies for all projects
communicate to mgmt the true cosst, objectives, risks for projects
establish which outside collaborations are sanctioned: not all collabs are equally valued by mgmt. 

improvements:
develop instruments faster in response to sci requests
est expertise in 2-3 key technologies
schedule formal, informal mtgs with scientists, fellow engrs, collabs
participate more effectively in the proposal process
address emeging opportunities in ocean sci

Improving Process:
how is research done?
kill someone else's project, give me their resources
outside mbari, sci gets idea->sci get $->engr  builds->sci gets results

we have internal proposals, engr & sci do everything together, incl publishing

getting ideas: ad hoc


comments:
[can't do everything better, faster, cheaper: pick two]
less projects, more meetings
group leaders should encourage engrs to go to certain mtgs, presentations

sci/ops should be an active part of the team doing strategic planning
[yes! and they must contribute to deliverables]
bypassing instrs is an advantage -- core is flooded w/ projects, and can pick and choose from the opportunities streaming by.

Success depends on assembling the team that is assembled to do a project. Not everyone can be rotated in/out.
Team disruption is harmful, especially for long term projects.
Need a way to stop projects, and start up new ones on a dime

involvement, being dicatated to

involvement implies responsibility - leadership needed to keep attention focused on right thing at right time. 

*group leads key in deciding when to be involved, when to focus on other work.
*group leads need to monitor what's important and steer people to important things

[need to understand how successful ideas happen, how failures happen]
*we don't follow sci and industry directions well
*need to follow board, foundation values
WHY don't we track sci/tech directions well?
*librarian at hopkins
[we don't invest the time and account for the time]
need to look at what we do internally first -- we don't know what's going on down the hall so we don't duplicate effort: e.g. pH sensors Gernot has been doing forever, but no one uses him for this.

[rajan] all the publishing, conferences, talks etc. are important.
Brown Bag lunches might be helpful

peter brewer is very good at making project team is aware of what's going on...need to show an interest and ask questions. Sci willing to educate you.

how far does this education go (individual?)
* science wikis could extend benefits of education

*projects could start with relevant science overview
*read reports, visiting committee report, annual reports
some are forward looking, some look back

we're talking about ways of connecting with science formally, informally
*find a topic of science that is interesting and make that happen, attach to scientists


*day of science and technology : one day of sci presentations to find interests to latch onto

-why we have pjt updates: no way to coordinate everyone for two days and limit time to 15 min, so pjt updates were made. shouldn't do both.
-one is for 'crazy ideas' the other is for seeing what's been done
-scientist time is hard to get
-extend day of sci/tech to 

*[use forums/wikis to shoot ideas around rapid fire...people can nucleate, read threads, faqus to catch up, form activity groups]

Example Science Theme:
-Observations/experiments
-Technological needs
*again, how much time is scientist willing to commit/invest in a direction/technology
need to cast problems in terms of what science needs to make impact, and can we do it?

proposal process:
*insert SEC before mteam to filter proposals

*[there need to be time to focus, time to research, mechanisms to respond to asynch opportunities]
*[need to be able to consistently design and execute ONE project successfully at will, then figure out how to scale it up to more projects]

what does SC do?
add information for proposal projects, mteam
makes sure projects are reasonably scoped
only mteam approves/denies projects
participation optional

how we can execute better:
staging could be better
stop reinventing the wheel: innovate at the application layer - it's the level that distinguishes it from other products

Action Items:
*document sci/tech development in/out of MBARI
*set up structs to influence proposal process
*insist on exit strategy and transistion point for push projects
*figure out how to elicit science themes
*establish a framework for tech push engr research projects

In Lab Engineering [jannasch]:
how do you work w/ engrs
what works well
issues/concerns
levels of cooperation
modes of cooperation
-dependent
-highly integrated
-design and build (funded in pjt)
-please design and build (not funded in pjt)
-bypass engr and got to DMO
-outside contracts
-outside commercial collaborations (digiscanner, ISUS; they redesign and productize)
-mostly independent (e.g., sw developers, chem sensors lab)

b/c flexiblility wrt design, proposal process. e.g. diffusion cell fluid transport -- could just order up some parts and make something quickly. Hard to do in current paradigm; not in a proposal process. Depends on where engineer is fully involved. Difficult to respond to changes quickly -- needs full engr buyin and background from the start)
Changes to project direction has neg impact in terms of resources slowing, stopping, changing direction.

please design and build: how many engrs are doing this? it's a resource drain

positive feedback:
accomplishments (ROV, AUV, control systems, data mgmt)
resources (past, current efforts)
wide knowledge base
great engrs/technicians (especially 1:1 basis)
willingness/eagerness to help, brainstorm and share

Issues raised:
-MOOS/MARS eat >> 50% resources
-Smaller pjts fall thru cracks
-Lack of clear ownership/responsibility for pjts
-Difficult to interest engrs in less cool but needed developments
[is this a question of best use of core engr]
-Over engineering: nice design/not useful, nice design/only supposed to be prototype
*clear written requirements/specs help reduce over-engineering
*need to capture use cases through project lifecycle (sci/engr/ops together)
*how does 'it' get to a not useful state w/o scientist flagging it? communication lapse between phases

-Projects w/o a cruise deadline often delayed (Support Engr)
-Difficulty doing routine jobs (cost brownie points/guilt by asking friends)


Research and Engineering [kolber]:
photonic devices

[platforms presentation ]1200-1630 (less lunch, break)

[matsumoto]outreach


Todo:
*send out slides, notes, draft plan

Wrap up:

-process:
standards, when are they appropriate

-proposals:

-culture:
internal day of science and tech and operations
cruise participation
lab leads
oceanography 101
what are we asking engineers to do: are all engrs the same
are we doing too many projects

-structure:
tech leads
strategic council (from last offsite)
who's on group council: sr engrs., experts (tasked non-council, external)

todo - 
*needs to be SC to pull together roadmaps
*decide composition, roles, responsibilities, authority, interfaces
*pull in science, ops