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

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 Investigate site requirements Identify site owner, stakeholders Develop and signoff specification Develop site Test site Conduct test group training Publish site Review site and training Conduct user training 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?

4. Overview of structured process 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 Identify need for site Investigate site requirements Identify site owner, stakeholders Develop and signoff specification Develop site Test site Conduct test group training Publish site Review site and training Conduct user training

5. Overview of structured process 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 Identify need for site Investigate site requirements Identify site owner, stakeholders Develop and signoff specification Develop site Test site Conduct test group training Publish site Review site and training Conduct user training

6. Overview of structured process 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 Identify need for site Investigate site requirements Identify site owner, stakeholders Develop and signoff specification Develop site Test site Conduct test group training Publish site Review site and training Conduct user training

7. Overview of structured process 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 Identify need for site Investigate site requirements Identify site owner, stakeholders Develop and signoff specification Develop site Test site Conduct test group training Publish site Review site and training Conduct user training

8. Overview of structured process 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 Identify need for site Investigate site requirements Identify site owner, stakeholders Develop and signoff specification Develop site Test site Conduct test group training Publish site Review site and training Conduct user training

9. Overview of structured process 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? Identify need for site Investigate site requirements Identify site owner, stakeholders Develop and signoff specification Develop site Test site Conduct test group training Publish site Review site and training Conduct user 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

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