Product Management – Concepts – circa 2000
My focus has always been on quality, continuous improvement and excellence of execution. Delivering services using well defined approaches[1] is critical to achieving these things.
Approaches [3] deliver products and services [2]. Each approach has:
- a set artefacts (e.g. deliverables[4]) which there should be templates for and examples of.
- a process i.e. a sequence of Steps (and sub-Steps), Steps are performed by Roles who use Tools and apply Techniques);
This ensures services are delivered in a consistent and repeatable way, and assists in classifying artefacts and developing metrics e.g. for Steps, Artefacts, etc.
Highly adaptable approaches which can be easily instantiated[6] and adapted allows for continuous learning. Approaches that attempt to obviate the need for judgement and experience are doomed to failure[7]. Approaches can always be improved and need to constantly be assessed for gaps, areas of improvement, changes in underlying technologies or environment. etc.
Common tooling (and language, notation, syntax and format) is key to effectively getting people using common approaches[8] and managing complexity[9]. Basic modelling that allow elements of types and associations between those elements is fundamental. Models can be present in many ways e.g. tables, forms, diagrams etc.
Approaches need to lead by owners who will act as a focal point for ongoing development of the Approach. They will also try and stay abreast of industry and academic developments and assist in knowledge transfer by understanding who is applying the approaches, what they have know and learnt, what they have produced and any problems encountered. Their knowledge will be useful during instantiation and their reviews they highlight where approaches can be improved.
Approach owners would ideally QA all work done with an Approach until they are confident a practitioner has developed enough experience in the use of the Approach to apply it successfully.
Universal access is critical so that teams of people can work together independent of location. So repositories need to established that are accessible from anywhere (over the internet). All documents of record (e.g. contractual, deliverables and key supporting artefacts should in these repositories.
Critical to improving metrics is understanding the effort associated with each Step, and/or Artefacts[10]. For this reason we favour high level plans (or task lists) and the recording the effort against them. If we don't record how long a class of task or artefact has taken in the past we have no basis for estimating how long it can be expected to take in future.
Approaches can be defined at different levels of detail. There has been much debate regarding the best format for representing the products. What we are trying to achieve is a consistent way of representing approaches. The current view is that products will be represented by:
- Brochure – that summarises the benefits and broadly outlines the approach.
- Presentation – that summarises the approach, its objectives, challenges to be overcome and the steps to be undertaken.
- Model(s) – process models that provides an overview of process
- Document(s) and/or Wiki – a narrative describing the overall process, sub-processes and discrete steps (often with reference sources, useful tips on techniques, etc.)
- Artefact lists – derived from the approach model (and often presented with default metrics) as a spreadsheet. They may be elaborated in discrete documents.
- Artefact templates – for each artefact/model
- Artefact exemplars – for each artefact/model
- Role descriptions – usually recorded in the approach model (may be elaborated in documents).
- Work template – a simple set of steps and schedule (steps, key dependencies etc.).
Approaches should provide an overview[11] for experienced practitioners. The approaches may be terse and to the point[12]. It is not expected that anyone other than an experienced practitioner, or someone mentored by an experienced practitioner can successfully apply the approaches.
Approach use
When a project is established we will establish a discrete project repository. Copies of standard artefacts templates will usually be put in this repository (its categories, documents types will reflect the areas/steps of the approaches)
Approach model – will be either used as is or adapted as required.
Steps – will be recorded in a plan and each step will be sized and resourced as appropriate.
Work and Artefacts – work will be undertaken and artefacts will be created
Current technologies (i.e. what we should use)
Documents: spreadsheets, word, presentations, diagrams
Models: sets of components that are related
Diagrams: based on models where possible.
Plans and schedules
Document repositories
Generic communications: email, IM, Wiki, etc.
[1] Sometimes called methodologies or processes.
[2] Sometimes called offerings
[3] Typically delivered in the context of a project or assignment
[4] I take a Miessian view of deliverables (i.e. “less is more”) and distinguish work products and deliverables
[5] Examples should be evaluated to see if they represent best practice
[6] The generic roles, artefacts and steps etc. be adapted, amalgamated, or put aside.
[7] Based on empirical experience (e.g. with organisations touting methodologies as silver bullets)
[8] Experience shows that Word document based approaches fail and Systems oriented approaches too expensive and inflexible.
[9] See: The Challenges of Complex IT Projects [British computer society; Royal Academy of Engineering]
[10] Often this is considered impractical in a plan because many tasks relate to many deliverables.
[11] Check lists, handy templates, memory joggers etc.
No comments:
Post a Comment