Structured development process

1. Structured development process Brett Coster Business Analyst uniqueworld brett.coster@uniqueworld.net Wednesday 20 September 2006

2. Agenda • Who is this bloke? • Overview of structured process • Obtaining the user’s requirements • Questions to consider • Whose spec? writing for the user, the business and the developer • Case study: Widgets Co • Acceptance testing • Summary • Your questions

3. Overview of structured process Identify need for site • Identify the need for the site • Reasons for the site • What information do we want to make available? • Who do we expect to read or use the information • What do we expect people to do with the information? Investigate site requirements Identify site owner, stakeholders Develop and signoff specification Develop site Test site Conduct test group training Publish site Conduct user training Review site and training

4. Overview of structured process Identify need for site • Investigate site requirements • Presentation/s of how SharePoint works and the process to be followed • Orientation meeting and discussions with stakeholders and participants • One-on-one interviews, group discussions and meetings, and workshops Investigate site requirements Identify site owner, stakeholders Develop and signoff specification Develop site Test site Conduct test group training Publish site Conduct user training Review site and training

5. Overview of structured process Identify need for site • Identify site owner, information managers, stakeholders • Site owner and information managers: • Provide knowledge of the type, extent, security, and use of the information to be published • Identify ownership of the data • Identify how it can best be presented to site users • Identify roles to be used and who they apply to. • The information managers’ operational knowledge of the data and how it is used is crucial • Identify critical metadata to be applied to documents and information Investigate site requirements Identify site owner, stakeholders Develop and signoff specification Develop site Test site Conduct test group training Publish site Conduct user training Review site and training

6. Overview of structured process Identify need for site • Develop and signoff site specification • Build, negotiate and approve a development plan, specification/s, and schedule • On business unit signoff, the site is developed and unit tested Investigate site requirements Identify site owner, stakeholders Develop and signoff specification Develop site Test site Conduct test group training Publish site Conduct user training Review site and training

7. Overview of structured process Identify need for site • Develop site • Develop site structure and functionality • Use standard web parts and existing functionality wherever possible • Configuration • Develop specialised or one-off functionality where required Investigate site requirements Identify site owner, stakeholders Develop and signoff specification Develop site Test site Conduct test group training Publish site Conduct user training Review site and training

8. Overview of structured process Identify need for site • Testing, training and publishing • Train the core group of business unit testers to test and evaluate the site – acceptance testing • Testing may involve refinement and modification of the ‘as built’ site, as user capabilities evolve and active evaluation of how the information is used is revised • Production data – documents and list items – is populated as part of the testing process • On completion of the testing process, the site is published Investigate site requirements Identify site owner, stakeholders Develop and signoff specification Develop site Test site Conduct test group training Publish site Conduct user training Review site and training

9. Overview of structured process Identify need for site • Reviewing site and training • Post implementation review • Does the site do what we set out for it to do? • Are the end users managing the data? • Are they using the site? • What did we do right? • What did we get wrong? • What could be done better? • Where to next? Investigate site requirements Identify site owner, stakeholders Develop and signoff specification Develop site Test site Conduct test group training Publish site Conduct user training Review site and training

10. Obtaining the user’s requirements • Workshops • Pros: • Get lots of differing viewpoints • Often allows ideas to be tested, explored and decided on • Can identify commonality of processes • Can determine terminology for metadata • Can get consensus on big picture and way ahead • Cons • Can degenerate into chaos • One or two dominant people could inhibit or direct discussion • Hard to get everyone into same place at same time • May not be able to go as deep into tasks, information, processes

11. Obtaining the user’s requirements • Interviews • Pros • Often get deeper access to individual’s view of information and processes • Can follow up threads to get clearer view • Sets up personal relationship, know who to contact when questions or more information arise • Cons • Can be time consuming • Lots of similar ground covered • Can get bogged down in detail

12. Obtaining the user’s requirements • Documentation • Pros • Available to people outside original group • Shows decisions made • Cons • Does anyone actually read it? • Can become task in itself

13. Questions to consider • Site content • What types of documents? • How many? • Who owns, approves or controls the documents? • Do we need approval process? • Do we need version control? • Who’ll manage old versions? • Who updates the information? • Where are the people who use the information? • Are there bandwidth constraints? • Do remote users update information or only need access? • How long should it remain? • Is archival process needed?

14. Questions to consider • Site structure • Where is the information now? • On network? • Personal drives? • Existing intranet/internet pages? • How is the information organised and categorised? • Can this structure be used as metadata? • What other metadata do we need? • Site management and maintenance • Who will be the site owner? • Do we need local administrators? • Who will manage the site and its content? • Should everyone be able to add/change information? • Who/how many should be approvers?

15. Whose spec? Writing for the user, the business and the developer • Use templates • Consistent document structure • Consistent format • Let Word do the work for you! • Styles • Autotext • Change record sheets • Looks professional – Is professional! • Separate business information from the technical information • Provide page mockups • Show people what they will be getting • Tell the reviewers what part of the document you want them to review • Not everyone needs to read the techie stuff!

16. Widgets Co – Case Study

17. Widgets Co – Case Study

18. Widgets Co – Case Study

19. Widgets Co – Case Study

20. Widgets Co – Case Study

21. Widgets Co – Case Study

22. Widgets Co – Case Study

23. Widgets Co – Case Study

24. Acceptance testing • Train the testers • Outline the testing process • Goals • What to look for • Emphasise they cannot break the site • Play first, get comfortable, then use real data • Only when start using real data that really get feel for how site will work • Use it day to day • Accommodate tweaks and new features • But have a line drawn as to what is modification and what is new development • Finish with populating live data

25. Summary • Overview of structured process • Identify need, key stakeholders, site owner, information managers • Specification must address business, users and developers • Get users to use real data in testing • Obtaining the user’s requirements • Combination of workshops and interviews • Questions to consider • Who will use information? Why? What for? • Who will manage the information? How much? • What metadata do we need? • Where is the information now? • Whose spec? write for the user, the business and the developer

26. Questions? • Brett.coster@uniqueworld.net