Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cat Herding and Community Gardens: Practical e-Science Project Management

1,221 views

Published on

A talk given by Neil Chue Hong at the e-Science Project Management Symposium looking at issues and models of managing projects which are cross-organisation, cross-discipline and cross-usertype, based on experience of managing several e-Science projects.

Published in: Economy & Finance, Business
  • Be the first to comment

Cat Herding and Community Gardens: Practical e-Science Project Management

  1. 1. Cat Herding and Community Gardens: Practical e-Science Project Management Managing for Usability: Challenges and Opportunities for E-Science Project Management 10-11 April 2008, Oxford Neil Chue Hong
  2. 2. In a sense, this is what we do…
  3. 3. Managing People is like Herding Cats <ul><li>Dave Platt, referring to managing senior programmers </li></ul><ul><ul><li>origins of phrase lost </li></ul></ul><ul><ul><li>now used everywhere </li></ul></ul><ul><li>Co-ordinating skilled people with differing personal goals within a difficult situation </li></ul>
  4. 4. But what we want is Community Gardens <ul><li>Jointly cultivated by groups </li></ul><ul><li>Responsive and responsible to immediate community </li></ul><ul><li>Pooled resources and experience </li></ul><ul><li>Collectively organised </li></ul><ul><li>Learn and trade from other communities </li></ul><ul><li>Sustainable on lower resources and input </li></ul><ul><li>&quot;I no longer complain about the poor quality; I do something about it.&quot; </li></ul><ul><li>See: S. Chaplowe, Havana's Popular Gardens: Sustainable Urban Agriculture, World Sustainable Agriculture Association, Fall 1996, Vol. 5, No. 22 </li></ul>
  5. 5. How do you stop herding cats? <ul><li>… and start cultivating gardens? </li></ul>
  6. 6. OMII-UK: Software Solutions for e-Research <ul><li>OMII-UK provides software and support to enable a sustained future for the UK e-Science community and its international collaborators. </li></ul><ul><ul><li>Core support and development: £7.8 million </li></ul></ul><ul><ul><li>Commissioned Software Programme: £1.4 million </li></ul></ul><ul><ul><li>ENGAGE: improving access to e-Infrastructure: £0.9 million </li></ul></ul><ul><ul><li>Phase II: 2006 - 2009 </li></ul></ul>
  7. 7. OMII-UK: For all kinds of users Taverna: effortless workflows for scientists OGSA-DAI: data integration for service providers PAG: AG videoconferencing for anyone Campus Grid Toolkit: easy to install grid for job submission
  8. 8. OMII-UK: What we do and how we do it Development Support Evaluation + QA Outreach Community Commissioning (100%) 21% 7% 20% 5% (37%) 37% 10% PALs ENGAGE (15%)
  9. 9. The Four Levels of e-Science Enlightenment <ul><li>1) Resources: Providing access to a larger and wider diversity </li></ul><ul><li>2) Automation: Repeatability and management of experiments </li></ul><ul><li>3) Collaboration: Intra + cross disciplinary networks </li></ul><ul><li>4) Participation: Increasing access to a wider set of users; increasing knowledge in a domain </li></ul>
  10. 10. Why are e-Science projects different? <ul><li>Researchers + Computer Scientists + Software Developers </li></ul><ul><li>Many PIs </li></ul><ul><li>Few sanctions </li></ul><ul><li>Lack of common goal </li></ul><ul><li>Need to engage users </li></ul>User Satisfaction Cool Code Research Progress Job Stability
  11. 11. Have a common goal <ul><li>Or you will always be herding cats! </li></ul><ul><li>Decide or define this goal with your team </li></ul><ul><li>Understand how you will reach the goal together </li></ul><ul><li>This is the hardest thing to achieve but also the most effective </li></ul><ul><ul><li>a common goal means a common direction </li></ul></ul>
  12. 12. Balancing priorities against a goal
  13. 13. People power <ul><li>Social engineering is the key </li></ul><ul><ul><li>Get the organisation right </li></ul></ul><ul><ul><li>Push decisions down to the right level </li></ul></ul><ul><ul><ul><li>“ Too many chiefs” in most eScience projects </li></ul></ul></ul><ul><ul><li>Understand your teams </li></ul></ul><ul><ul><ul><li>Different people like working in different ways </li></ul></ul></ul><ul><ul><ul><li>Make sure they’ve met face to face </li></ul></ul></ul><ul><ul><ul><li>Go to the pub </li></ul></ul></ul>
  14. 14. A typical e-Science project organisation? 10 partners Steering Group Investigators Researchers Students Project Managers Developers
  15. 15. One for all and all for one <ul><li>Everyone is remote once one is remote </li></ul><ul><li>We don’t need heroes in a team </li></ul><ul><li>Collective responsibility still requires owners </li></ul><ul><li>Competition is good, so go one better </li></ul>
  16. 16. Dashboards in your common infrastructure
  17. 17. Little by little <ul><li>Agility is all </li></ul><ul><ul><li>big, complex projects = high risk of failure </li></ul></ul><ul><ul><li>adopting incremental approaches to requirements, design, and implementation helps minimise risk </li></ul></ul><ul><ul><ul><li>don’t timebox research, but do timebox development </li></ul></ul></ul><ul><ul><li>delivering small increments regularly is good </li></ul></ul><ul><ul><ul><li>good for quality, for visibility, for morale </li></ul></ul></ul><ul><li>Keep your eyes on the road </li></ul><ul><ul><li>keep an active eye on project risks </li></ul></ul>
  18. 18. What I really, really want <ul><li>Requirements, requirements, requirements </li></ul><ul><ul><li>write ‘em down! Give ‘em numbers! </li></ul></ul><ul><ul><li>remember, requirements aren’t just functional! </li></ul></ul><ul><ul><li>whatever they are, they are always testable </li></ul></ul><ul><ul><li>everything can’t be a high priority! </li></ul></ul><ul><li>Make sure you can understand their worth </li></ul><ul><ul><li>real users better than good ideas </li></ul></ul><ul><ul><li>user groups focus development </li></ul></ul><ul><ul><li>do just enough to make it work </li></ul></ul><ul><li>How do you effectively engage users in a distributed team? </li></ul>
  19. 19. Intelligence Analysis Group Management Ops Remit: make the best use of the available intelligence information to produce a three monthly digest Composition: 1 from Ops, 1 from Management 1 from each site team (one Chairs) <ul><ul><li>Honest (independent?) assessment of components </li></ul></ul><ul><ul><li>User Requirements analysis e.g. SUPER </li></ul></ul><ul><ul><li>Software Catalogue registrations </li></ul></ul><ul><li>Send people out to communities </li></ul><ul><ul><li>User surveys and followups </li></ul></ul><ul><li>Performance/Useability </li></ul><ul><ul><li>Customer requests </li></ul></ul><ul><ul><li>User forum </li></ul></ul><ul><ul><li>“ NERC community are going to stop using our products if we don’t fix bottlenecks in our workflow” </li></ul></ul><ul><ul><li>“ If we form an alliance with e-Minerals then we can build developer tools which will be useful” </li></ul></ul>Digest intelligence Suggest priorities Suggest actions Prioritise actions Results of actions from last cycle Implement actions Intelligence Analysis Group
  20. 20. Handling relationships
  21. 21. ENGAGE: developing new users of e-Infrastructure <ul><li>JISC funded, OMII-UK and NGS </li></ul><ul><li>Work with e-IUS/e-Uptake, follow up on SUPER, target individual research groups </li></ul><ul><ul><li>Capture research scenarios </li></ul></ul><ul><ul><li>Collaborate on e-Infrastructure designs </li></ul></ul><ul><ul><li>Implementation and deployment </li></ul></ul><ul><li>Aim to create specific examples of research benefit from e-Infrastructure </li></ul><ul><li>Get “non e-Science” groups to participate </li></ul>Use and Deployment Development and Integration Interventions Training Support Design Document and Disseminate Study Practice, Barriers, Enablers and Requirements ENGAGE
  22. 22. Make it easy for others <ul><li>Document! Document! Document! </li></ul><ul><ul><li>Imagine trying to program without a language reference </li></ul></ul><ul><ul><ul><li>structure and stability is good </li></ul></ul></ul><ul><ul><li>Get people who like writing documents to do them </li></ul></ul><ul><ul><ul><li>but get everyone to doc their code </li></ul></ul></ul><ul><ul><ul><li>A single editor can provide guidance </li></ul></ul></ul><ul><ul><li>Good code documentation can be used by the tooling </li></ul></ul><ul><ul><li>Good human documentation will win your users support </li></ul></ul><ul><li>Make sure you don’t underestimate the cost </li></ul><ul><ul><li>code maintenance takes longer than code development </li></ul></ul><ul><ul><ul><li>make it part of the process </li></ul></ul></ul><ul><li>Keep things transparent and available </li></ul><ul><ul><li>knowledge shared is easier for your community and easier for your team </li></ul></ul>
  23. 23. A good workman… <ul><li>Know your tools </li></ul><ul><ul><li>Good tools can increase productivity </li></ul></ul><ul><ul><ul><li>CVS, Ant, Bugzilla, Rational Rose, … use what suits </li></ul></ul></ul><ul><ul><li>Communication tools are as effective as code tools </li></ul></ul><ul><ul><ul><li>IRC/IM, Wiki’s, website, email </li></ul></ul></ul><ul><ul><li>The best tools are the ones which people use </li></ul></ul><ul><ul><ul><li>being prescriptive doesn’t always work </li></ul></ul></ul><ul><li>What to do when software you rely on changes? </li></ul><ul><ul><li>Know your versions! </li></ul></ul><ul><ul><ul><li>DLL hell, JAR war, … </li></ul></ul></ul><ul><ul><li>Don’t expect others to be sympathetic </li></ul></ul><ul><ul><ul><li>keep packages small (common, core, client, interfaces) </li></ul></ul></ul>
  24. 24. And for my final tip <ul><li>Balance the hype </li></ul><ul><ul><li>eScience project management is about vision vs effort vs requests </li></ul></ul><ul><ul><li>researchers, developers, users and funders are all different </li></ul></ul><ul><ul><ul><li>and all want different things </li></ul></ul></ul><ul><ul><ul><li>get it right for one community first </li></ul></ul></ul><ul><li>Don’t mess with your users </li></ul><ul><ul><li>it has to install easily </li></ul></ul><ul><ul><li>examples and tooling help </li></ul></ul><ul><ul><li>support is better </li></ul></ul><ul><ul><li>being responsive is best </li></ul></ul>
  25. 25. So just remember <ul><li>Have a common goal </li></ul><ul><li>People power </li></ul><ul><li>One for all, and all for one </li></ul><ul><li>Little by little </li></ul><ul><li>What I really, really, want </li></ul><ul><li>Balance the hype </li></ul><ul><li>Go to the pub </li></ul>

×