Book contents
- Frontmatter
- Dedication
- Contents
- Figures
- Tables
- Foreword
- Preface
- Acknowledgements
- Overview of the Book
- 1 Knowledge Driven Development: What is the Proposition?
- 2 Project Delivery and Supporting Methodologies
- 3 Project Delivery Pain Areas and the Way Forward
- 4 Project Knowledge Model: Context and Definition
- 5 Project Knowledge Model: A Differentiator
- 6 Project Knowledge Model vs Project Documents
- 7 Extending Project Knowledge Model to Cover End-to-End Project Delivery – KDD
- 8 Extended KDD: Pre-Requirement and Post Delivery
- 9 KDD Compliance with Standards of Project Delivery
- 10 Enabling DevOps
- 11 Addressing Contemporary Concerns of Project Delivery
- 12 Helping Existing Methodologies
- 13 Technology Enablers: Tools and Automation
- 14 Suits Factory Model: Needs Cultural Change
- 15 Global Relevance of KDD: GKMF Assisting Skill Development
- 16 Lean KDD: Elimination of Requirement and Test Design?
- 17 Conclusion
- Appendix A Illustrative Non-Functional Attributes
- Appendix B Compliance of PKM with GKMF
- Appendix C Project Estimate and Business Rule/Scenario Framework
- Appendix D Inventory Relationship for Setting up of Security Questions – as per Example in Chapter 6
- Appendix E KDD: Response to Criticism
- Glossary
- References
- Index
4 - Project Knowledge Model: Context and Definition
Published online by Cambridge University Press: 20 October 2018
- Frontmatter
- Dedication
- Contents
- Figures
- Tables
- Foreword
- Preface
- Acknowledgements
- Overview of the Book
- 1 Knowledge Driven Development: What is the Proposition?
- 2 Project Delivery and Supporting Methodologies
- 3 Project Delivery Pain Areas and the Way Forward
- 4 Project Knowledge Model: Context and Definition
- 5 Project Knowledge Model: A Differentiator
- 6 Project Knowledge Model vs Project Documents
- 7 Extending Project Knowledge Model to Cover End-to-End Project Delivery – KDD
- 8 Extended KDD: Pre-Requirement and Post Delivery
- 9 KDD Compliance with Standards of Project Delivery
- 10 Enabling DevOps
- 11 Addressing Contemporary Concerns of Project Delivery
- 12 Helping Existing Methodologies
- 13 Technology Enablers: Tools and Automation
- 14 Suits Factory Model: Needs Cultural Change
- 15 Global Relevance of KDD: GKMF Assisting Skill Development
- 16 Lean KDD: Elimination of Requirement and Test Design?
- 17 Conclusion
- Appendix A Illustrative Non-Functional Attributes
- Appendix B Compliance of PKM with GKMF
- Appendix C Project Estimate and Business Rule/Scenario Framework
- Appendix D Inventory Relationship for Setting up of Security Questions – as per Example in Chapter 6
- Appendix E KDD: Response to Criticism
- Glossary
- References
- Index
Summary
Project knowledge, which was notionally introduced in the previous chapters, is fully contextualised and defined in this chapter. The chapter begins by explaining what currently happens in the traditional project delivery regarding project knowledge. The complete definition of PKM is provided. At the end, an example of PKM is given to explain how it might look.
Traditional Project Knowledge Management
Knowledge, which is the combination of experience and research, is necessary to help IT industry, just as it is for all the other industries. IT industry will have two aspects: domain and technology. Domain is the collective knowledge, driven primarily by processes. Technology has implements such as programming languages that help putting that knowledge into useful outcome, most of the time it is software. Technology primarily helps in automating processes.
The automation that typically results in creation of software, is delivered via a project or programme. Knowledge plays a crucial role in software development and consists of business and technical knowledge. Typically, a software development project consists of four knowledge-intensive phases. The phases along with the document representing that phase is listed below:
1. Requirement analysis (business knowledge) – Business Requirement Specification Document
2. Solution design (business knowledge) – Functional Specification Document
3. Application design (technical knowledge) – High Level Design Document
4. Test design (business knowledge) – Test Case Document
This combination of knowledge is called ‘Project Knowledge’. Let us now understand how the Waterfall and Agile methodologies manage this project knowledge.
Project Knowledge Management in Waterfall Methodologies: Document Driven
Project knowledge is managed in the Waterfall methodology using documents. The main documents representing project knowledge are:
1. Business Requirement Specification (BRS) representing requirement analysis.
2. Functional Specification Document (FSD) representing solution design.
3. High Level Design (HLD) representing application design.
4. Test Cases representing test design.
Documents are authored by relevant stakeholders and are subject to review by the project team and SMEs, who may or may not be part of the project team. Post review, the documents are singed off and once a document is signed-off, changes to it are managed by version control. The next version of the document is also subject to the review cycle. Every time the next version of the document is signed-off, the information needs to be communicated to the entire project team.
- Type
- Chapter
- Information
- Knowledge Driven DevelopmentBridging Waterfall and Agile Methodologies, pp. 59 - 96Publisher: Cambridge University PressPrint publication year: 2018