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


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
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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>