Let the beauty we love be what we do.

1. Let the beauty we love be what we do. Dr. Ralph Young

2. Practical Project and Organizational Improvement Dr. Ralph R. Young Requirements Evangelist ryoungrr@aol.com www.ralphyoung.net May 26, 2010

3. What to do Best Practices How to do it Overcome Project Problems Human Behavioral Issues

5. Intent of this Webcast To provide an engaging presentation that is about you To communicate information that will make a difference Summarize industry experience Highlight requirements-related best practices Identify resources

6. A suggestion and request of you 6 • Use this time to consider ideas and suggestions to improve your work • Identify three things you would like to do differently at work (keep a list) • Commit to advocating and sponsoring them • Work with your peers and managers to use them • Use this experience to change your life • Positive change occurs only when someone commits to it!

7. Some Project Best Practices What are the REAL Requirements? Control Requirements Growth Create joint Commitment to Results Your Project Improve your Business Analysis Foster Continuous Improvement

8. Assertions 8 • The requirements are critical because they provide the basis for all of the work that to be performed. • Requirements rarely evolve well. • Poor requirements are a root cause of industry problems: • Lack of project success (< 50% of all projects) • Rework (45-50% of total project effort) • Processes are rarely defined, documented, and used.

9. Best Practices • Apply a continuous improvement approach • Work toward project and organizational maturity • Practice process improvement • Improve project start-up • Provide an early project requirements briefing • Identify the “real requirements” • Improve business analysis

10. Apply a Continuous Improvement Approach Clarify goals and objectives Ensure senior management sponsorship Define the vision and scope of the effort Evolve product delivery steps that are doable Identify and prioritize improvement opportunities Set expectations continuously (things change) Manage Achieve buy-in

11. Project or Organizational “Maturity” “The degree of effectiveness” Typical Process Areas • Project monitoring and control • Risk management • Requirements development • Project planning A useful framework for process improvement is The Capability Maturity Model for Software (CMM) (available at www.sei.cmu.edu/library/abstracts/reports/93tr024.cfm)

12. Profile of a “Mature Project” • Processes are defined and documented • Management plans, monitors progress, and communicates • Roles and responsibilities are clear • Product and process are measured • Quality, costs, and schedules are predictable • Management is committed to continuous improvement • Technology is used effectively within the defined process

13. Focus Level Process Areas (PA) Impact Productivity & Quality 3 Defined Process Standardization Process Improvement Risk Management Training Product Integration Validation Verification Risk Rework An Example of a “Process Framework” that you can apply 2 Managed Basic Project Management Project Planning Requirements Development and Management Project Monitoring & Control Measurement & Analysis Process & Product Quality Assurance Configuration Management

14. An ongoing quest to improve the range of expected results achieved from accomplishing a task or achieving an outcome. What is Process Improvement? Technology Process People

15. Why Do Process Improvement? • Continuous improvement is a business necessity • People are more motivated when contributing effectively • Job satisfaction contributes to retention and recruitment • Performing tasks efficiently contributes to business results • An environment and attitude of continuous improvement empowers the work force • A focus on getting “ever better” helps identify real and potential risk areas • Working toward excellence collaboratively with our customers fosters customer confidence

16. Higher quality Expected Business Benefits Reduced work Increased probability of project success Improved ability to meet schedules Greater stakeholder support Bottom line: Improved customer satisfaction, increased effectiveness, and a more committed and fulfilled staff.

17. Typical Requirements-related Project Start-up Issues Customer asks the developer to provide the requirements Lack of high-level requirements Unclear requirements Confusion reigns All stakeholders not identified Lack of effective communication Pressure to get going with the “real work”!

18. How to improve project start-upSuggested Remedies for Typical Requirements-related Project Start-up Issues Typical - Identify a champion for the project requirements process - Hire and train experienced requirements analysts - Write a project vision and scope document - Form and use a joint team - Provide an “Initial Project Requirements Briefing” - Design, document, and use the project’s requirements process - Evolve the real requirements - Select, deploy, implement, and use industry-proven best practices - Engage all project staff in the requirements process - Create a project Configuration Control Board (CCB) - Undertake team building among project staff - Use an automated requirements development tool

19. Requirements-related Startup Checklist

20. Suggested Topics for Early Project Requirements Briefing • Overview of the requirements for the project • The project’s “Requirements Process” • Overview of the methods, techniques, and tools that will be used • The criteria of a good requirement • Types of requirements errors and how these can be reduced • Use of versions, releases, and product updates Providing an “Early Project Requirements Briefing” facilitates engaging all members of the project team in the requirements effort.

21. How to evolve the “real requirements” (Reference: Chapter 4 of Effective Requirements Practices) 21 Identify and prioritize the real customer needs Evolve the real requirements using a variety of elicitation techniques Utilize “Criteria for a good requirement Ask: Why is each requirement needed? Drive errors out of requirements Prioritize requirements Ensure joint user and developer responsibility for the requirements “Joint Team” Invest additional time and effort at the beginning of the project

22. Use Your Expertise to Reduce Costs • Only 54 percent of the originally defined features of a project are delivered. • Of those features that are delivered - 45 percent are NEVER used.” • [The Standish Group. "What Are Your Requirements?" West Yarmouth, MA: The Standish Group International, Inc., 2003, Standish Group (based on 2002 CHAOS Report)] • So one could argue that more than half of the development cost of most projects is wasted effort. That is powerful information for customers who are willing to objectively evaluate the real requirements.

23. Types of Requirements Errors

24. How to Improve Business Analysis(Use the Requirements Engineering Handbook) Understand the roles of the business analyst/requirements engineer Define and use a requirements process Perform requirements planning Understand traceability Define what “quality means Utilize effective methods and tools Refine business analysis skills Provide a mechanism to control changes to requirements and new requirements

25. Thanks for your participation today! I trust that you have identified at least three things to change on your project, and that you are committed to enabling that change! PBEV

26. Thank you for attending ! Ken Berger VP Business Development Ken.berger@edevtech.com 416-469-3131 x225 inteGREATed Body of Knowledge 26