How can you best evaluate a solution before making the big investment? Over several years Mekon has worked with many companies, from medical and semi-conductor manufacturers to software and professional publishers, helping them to select a technology solution fit for purpose. Gathering requirements and choosing the right tools is often more difficult than many companies expect. Use cases and non-functional requirements that accurately reflect what you need are crucial to the success of any IT project, yet evidence suggests typical use cases and requirements are too loose and high level to really do the job. This presentation will: * Explain methods that Mekon has developed. * Evaluate customer experience in conducting the Conference Room Prototype (CRP). * Outline what metrics can be used to evaluate the tools and what surprises you may encounter.

1. Conference Room Prototype
a low cost, high value approach to selecting the
@Aerojules #LavaCon
solution you really need
Julian Murfitt – Mekon

2. About the Speaker
~ CEO and co founder of Mekon in 1990
~ Engineering back ground
~ Focused on structured technical
content for over 20 years
~ Personal interest in extreme forms of flying
~ Julian.murfitt@mekon.com
~ @aerojules

3. Company overview
~ Founded in 1990
~ Approximately 30 expert staff
~ Specialists in content / document-centric
business processes
~ Supplier of consulting, systems integration and
development services
~ Leaders in delivery and personalised content
~ The makers of DITAweb

4. Collaboration
Dynamic
content
PLM
Translate
CCMS
CRM LMS
The content lifecycle

5. A Conference Room Prototype
drawn from past experience
• Developed over many years
• Medical Device, Software,
Professional Bodies, Semiconductor,
manufacture, Exam boards,
Governments
• Vendor independent
• CRP carried out on CCMS from:
• Ixiasoft, Vasont, SDL, Bluestream,
EasyDITA, Astoria, Componize

6. Government / Professional
Publishing
Cross–industry experience
Commercial / High Tech
/ Engineering
Aerospace and Defence

7. Audience
~ Who are you?
~ Why are you at LavaCon?
~ What stage are you at in your CS process?
~ XML, DITA?

8. Initial assumption!
~ A process of evaluation has taken place
~ You have a Content Strategy
~ There is a need for change
~ DITA has been established as a way forward
~ You have an idea of scope and
an area to focus on

9. Project failure
~ IBM: only 40% of IT projects meet schedule, quality and budget goals
~ The Portland Business Journal: between 65% and 80% of IT projects
fail to meet their objectives, they also run late or cost more than
planned
~ McKinsey: half of IT projects run 45% over budget, are 7% behind
schedule and deliver 56% less functionality than predicted
~ KPMG: 70% of organizations have suffered one or more project
failure in the previous 12 months
~ ZDNet: according to new research, success in 68% of technology
projects is ‘improbable’. Poor requirements analysis causes many of
these failures, meaning projects are doomed right from the start

10. Top 12 dominant risks
Lack of top management support
Lack of documented reqs. and/or success
criteria
Weak project manager
No change control process (change
management)
No stakeholder involvement and/or
participation
Ineffective schedule planning and/or
management
Weak commitment of project team
Communication breakdown among
stakeholders
Team members lack requisite knowledge
and/or skills
Resources assigned to a higher priority
project
Subject matter experts are overscheduled No business case for the project

11. People related risks Process related risks
Lack of top management support
Lack of documented reqs. and/or
success criteria
Weak project manager
No change control process (change
management)
No stakeholder involvement and/or
participation
Ineffective schedule planning and/or
management
Weak commitment of project team
Communication breakdown among
stakeholders
Team members lack requisite knowledge
and/or skills
Resources assigned to a higher priority
project
Subject matter experts are
overscheduled
No business case for the project
Top 12 ranked risks

12. Human factors
How to avoid a CS plane crash

13. What do we mean human factors?
“Human factors involves gathering
information about human abilities,
limitations, and other characteristics and
applying it to tools, machines, systems,
tasks, jobs, and environments to produce
safe, comfortable, and effective human use”
Boeing

14. Mental model

15. Only perceive what you can conceive

16. Only perceive what you can conceive

17. DITA is challenged from the start
Tweet @joepairman
DITA is a
metamorphous
change

18. Despair on the forums
How do I make a word “green “
in DITA GREE
N ~ A DITA implementation isn't a tool swap
That way of thinking leads to dashed hopes and broken
dreams.

19. The Old way
~ Requirements maybe an RFI/P
~ Demo – 2 Hours!
~ Feature fest
~ Often Vendor set the agenda for
implementation
– Shoe horn your requirements into their way of
thinking

20. Test drive
~ Car

22. Conference Room Prototype
• Hands on session 2 days
• Support by Vendor tech lead
• Independent expert to guide you
• Cross section of your team
• Some initial training to orient users
with basic tech framework and
principles
• Defined requirements and user stories
• Gather formal lists of actions and
discussion points
• Identify and mitigate potential risks

23. Meet the team
There is no one typical Tech Author.
~ Developers / engineers
~ DTP / graphic designers
~ Journalists
~ Marcomms professionals
~ Localisation professionals
~ Frustrated poets
…..and no one stake holder in your project

24. Choose the team (Cont.)
~ A sense of ownership makes people happy
~ You will need to develop new roles
~ Look out for champions or specialists
– Metadata, re-use, output generation

25. Orientation Session
~ What benefits can structured content bring?
~ What are the basic building blocks (and how
do they fit together?)
~ How might my regular work change when
working with structured content?

26. User Stories
~ Clearly capture:
– User needs
– Actions
– Workflow
Who
What
Why!

27. User Stories: previous approach

28. Did we lose sight of the real need
~ Form of transport

29. User Stories: new approach
~ Activities are the main stages of developing a
publication (creating a new publication,
authoring, reviewing, releasing…)
~ User stories cover all the key functionality of a
CCMS
~ Acceptance criteria are the various ways in
which a system could complete the user story

30. User Stories: new approach

31. US #1
As an author, I want to be able to create a topic
from a template, so I can easily keep to the
standard structure.
Acceptance criteria:
– When creating a topic, I should be presented with
available template options
– The template options should have clear
descriptions or a visual preview so I can easily
choose the correct one

32. US #2
As an author, I want to enter metadata when
creating a new topic, so the team can easily find
the topic and so we don’t need to remember to
go back and add metadata later.
Acceptance criteria:
– I can’t create a topic without entering at least any
mandatory metadata
– Where appropriate, the system allows me to pick
from centrally-maintained lists of values, so I don’t
have to remember the correct value and type it in
accurately

34. Scoring
~ When we complete an activity, take time to
score the user stories within it
~ Scoring helps us focus on the experience
~ Lower scores indicate items to follow up
Score Description
3 System can complete the user story in an efficient and effective way
2 System can complete the user story but with concerns for usability or
performance
1 System can partially complete the user story
0 System unable to complete the user story

35. Prototype Sessions
~ Experience DITA authoring with CCMS, and see how
the work day will change
– Builds on orientation session, and adds in crucial CCMS functionality
around version control, workflow, and collaboration
~ See how the system fulfils the user stories
– First hand experience of usability and functionality
~ Chance to ask questions about the system and
structured authoring best practices
~ Identify areas to follow up
– and mitigate potential risks
~ Gather formal lists of actions and discussion points

36. Capturing additional comments
~ Record any additional thoughts you have
~ How would your work day change if using the
system?
~ Many features will be unfamiliar —
– do you feel you can get used to them?
~ Don’t worry about being objective
~ How you feel about the system is important

37. Report and data collection

38. Filter

39. Not obvious
~ MM box

40. Immediate Follow-up
~ Hand in scores & comments
~ Interim report including scores and items to
research further
~ Follow up with vendor on questions and any
areas of concern
– Emails
– Concalls / screensharing

41. Steps
Step Purpose Mekon actions Client logistics Client team
involvement
Data conversion Realistic sample content to
work with
Convert sample
content
Provide sample
content [done]
-
Orientation
workshop (1 day)
Familiarize CRP
participants with structured
content/DITA
Prepare materials,
conduct workshop
Arrange date,
room, & equipment
Attend training
User stories and
other
requirements
Clearly capture user needs,
actions, and workflow
Draft and refine
requirements
Put aside time to
review report
Agree & prioritize
user stories &
NFRs
Prototype
sessions
(2 days)
Go through user stories in
the system
Arrange dates,
room, & equipment
Participate in
sessions
Interim report,
calls, webexs
Summarize prototyping,
identify areas to follow up
Prepare report,
organize followup
Availability as
necessary
Join calls, webexs
Web demos Detailed look at other
systems for comparison
Organize & host
web sessions
Availability for 1 or
2 2-hour sessions
Actively
participate in
demos
(More prototyping
if necessary)
(as initial prototype sessions)
Final report Summarize findings from Write report Put aside time to Review report

43. Compare the market.com
~ MoSCoW scores
– 3- Must Have
– 2- Should Have
– 1- Could Have
– 0- Won’t Need

44. Detailed Web Demos of Other Systems,
More Prototyping if Necessary
~ Can now ask more informed questions
~ Immunized against demo-itis!
~ Find out what kind of tradeoffs there are:
– Power
– Ease of use
– Conformance to standards
– Budget

45. Radar chart

46. Example client
Manufacture network analysis adaptors and
various accessories
looking to improve the end-user experience
Carried out CSA, PSP and then CRP
Mekon deployed a system using Xdocs, Oxygen &
Delta XML,
Produced there first set of DITA docs in 5 Months
from the CRP

47. What did you get from the CRP
~ Hands on experience of the system prior to
purchasing, ensuring it fulfilled our specific
requirements.
~ Use Case assessment of the system enabled us to
confidently make a decision.
~ Enabled us to get past the first impressions based on
user interface and flashiness, allowing us to evaluate
actual functionality compared to our specific needs.
~ The benefits of a system, which was three times the
price of the one we chose, were negligible.

48. Quick summary
~ Prepare
– Right team
– Carefully develop user stories
– Engage a vendor
~ Prototype session
– Collect feedback
– Score
– Review and Refine
~ Choose the system

49. Questions