Project Management Overview


Published on

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • International Institute for Learning, Inc. Tips and Tricks for the Business Analyst Version 2.0 Webinar Learning Series 1- © 2007 International Institute for Learning, Inc.
  • 1-
  • In the next hour we will be walking you through the IIBA’s Body of Knowledge while providing with some methods that will help you with the various knowledge areas within the BOK.
  • IIBA Milestones: 2003 – Board of Directors 2005 – Body of Knowledge 2006- 1 st Certification Exam The organization has over 3500 members in 57 countries.
  • Here we have a graphic of the IIBA BOK, which is the sum of knowledge within the BA profession and what is considered current accepted practice. There are 6 Knowledge Areas that cover the activities, tasks, and skills that a BA needs to be effective in his or her role. We should note, at this time, that IIL’s BA curriculum is completely aligned with this Body of Knowledge. Our courseware has been reviewed by the IIBA, and we have received “Endorsed Educational Provider” status from them. This is a good thing for those of you who may be interested in taking the Certified Business Analysis Professional (CBAP) exam offered by the IIBA. IIL’s BA courses not only help you learn the skills to be a more effective BA on the job, but they will help you to learn the content of the BABOK on which the CBAP exam is based. We will talk more about IIL’s BA curriculum later during this webinar. Right now, let’s take a moment to discuss the BA BOK in greater detail.
  • Enterprise Analysis EA: covers the pre-project or early project activities that align with the Concept Phase of the Product Life Cycle we discussed earlier. Work in this Knowledge Area is about capturing a high-level view of the business to provide context to requirements and design work and long-term planning. During Enterprise Analysis, the Business Analyst helps stakeholders define problems and opportunities , and high-level business requirements in the form of goals, objectives or needs of the enterprise. The BA helps conduct feasibility studies and prepares the business case (and any other information and analysis required) to support project selection. Generally, upon acceptance as a funded project, the BA edits the high-level requirements to accompany a project charter, which authorizes a project manager and additional resources to launch the project. Typical deliverables from this KA include Business Architecture, Feasibility Studies, Business Case documents, and Decision Packages.
  • One of the key activiites in Enterprise Analysis is to define the business problem being solved. If the problem being solved isn’t the right problem, then the resulting product is not likely to be the actual solution needed and therefore the project will be unsuccessful from the perspective of the user and the client. The next few minutes will be spent on how to increase your chances of uncovering the real problem so that your project won’t be off the mark from the start.
  • 1. This step is not a long process, however, it helps the BA to: Eliminate non-problems. Discover additional problems. Establish the acceptable level of confidence. Identify metrics for measuring and confirming solution. Recognize warning signs or triggers that are symptoms of the problem.
  • We need to weed out the candidates that are not the “real problem” through a systematic set of filters.
  • Ask: Who wants to solve each problem? Who cares how it is solved? Who might resist the solution? Who has authority to approve/disapprove the solution? Is the owner someone within the organization? Is the owner the one asking for the solution? If the answer is “No” to any of these questions, it isn’t our problem. Cross it off the list.
  • If the problem is temporary or anticipated (it will occur if some action is taken), then it isn’t relevant; eliminate it. If the problem is not current, it is not a problem (yet). ONLY DEAL WITH CURRENT PROBLEMS
  • If there is only one solution, then the statement is an implied requirement or a constraint on the solution, keep it as a requirement, NOT the problem.! E.g., insurance claims should take 3 days to process, but they are taking 5 days to process. The requirement: The system will process insurance claims within three days from receipt of the claim by the claims officer to the completed payment of said claim by the accounts payable department.
  • Definition of Symptom: 1. Any phenomenon or circumstance accompanying something and serving as evidence of it. 2. A sign or indication of something. We should be looking for the “something” . A reduction in productivity may seem like a problem to an executive, however, it is likely the symptom of a problem.
  • Minimize ambiguity by testing for: Language clarity and conciseness No implications of another problem Common understanding
  • In summary, the point we have been trying to make here is the importance of having a rigorous problem identification process in place. This helps the BA to: Gain management support (or expose the lack of it) Provide focus for information gathering sessions Mobilize and focus the development community Anchor the project in the one unchanging aspect of the project Provide a level of stability
  • A Vision Document (see sample on the next few pages of this workbook) is created relatively early in the development of a solution to document a high-level consensus among stakeholders as to the overall scope of the solution domain. It is most commonly written when a solution is to be developed iteratively. [IIBA BOK, R1.6, p. 206] “If, instead of a fully robust process, I were permitted to develop only one document, model, or other artifact in support of a software project, a short, well-crafted Vision Document would be my choice.” [Philippe Kruchten] In summary, the Vision document is a concise description of everything you consider most important about the product or application. Write the Vision Document in plain language and at a level of detail that makes it easy for the primary stakeholders of the project to review and understand the document. [Leffingwell & Widrig, Managing Software Requirements]
  • Requirements Planning & Management RP&M: defines resources & tasks associated with Planning & Managing Requirements gathering activities. [This Knowledge Area defines what the BA needs to know to work within any analysis process or overall solutions development methodology.] In RP&M, the BA must define what requirements activities will be performed and how they will be performed on a specific project, in accordance with any existing standards in the organization. As you can see, information from EA – [namely, business environment analysis, enterprise requirements scope & feasibility assessment] – become inputs to RP&M. Outputs from RP&M will determine how information will be gathered, analyzed, documented, and communicated to the stakeholders, as well as how solution assessment and validation activities will be done. The lines that exist between RP&M and the other boxes in the diagram reflect the iterative nature of the work the BA performs across the entire spectrum of requirements-related activities. The BA needs to develop, define, and manage the roles and tasks associated with requirements gathering in coordination with the PM to ensure that the activities are completed in the most efficient manner possible.
  • Plan requirements change Determine who should be involved in handling requirements changes. Define how requirements changes will be administered and communicated. Understand the changes to requirements Identify issues and changes. Participate in impact analysis. Document changes to requirements Create formal change requests. Define links to other requirements. Analyze change requests Obtain a greater understanding of the requirements change, operational context, and potential issues Categorize and prioritize requirements Submit changes for approval Track changes to requirements* Ensure each changed requirement is traceable back to its source Define links to other requirements * Track Changes to Requirements” is considered its own distinct activity within the task of Manage Requirements Change in IIBA BOK R1.4 (see p. 85-86). IIL’s subject matter experts agree with this designation, which is the reason we have presented the R1.4 list here. Note that in IIBA BOK R1.6, track changes to requirements is demoted to a sub-task beneath Analyze Change Requests (see p. 150-151), a designation which would seem to place a lighter emphasis on this activity. 1- © 2007 International Institute for Learning, Inc.
  • Requirements Elicitation is a key task in Business Analysis. RE: covers the STD techniques used to collect (or elicit) information from S/Hs. Since requirements serve as the foundation for the solution to the business needs, it’s essential that they be as complete, clear, correct, and consistent as possible. Leveraging proven means to elicit information will help to meet these quality goals. Again, the arrows pointing to and away from RE suggest the iterative nature in which the BA works to gather information from stakeholders.
  • In the world of the BA, the term Gathering Requirements is common – but do we really gather requirements? Or are we getting information from various stakeholders and subject matter experts to better: Understand the scope of the product to be delivered. Understand the current state and desired state. Discover gaps and inconsistencies in the current system. Have complete information on regulatory constraints. Make sure there is a complete picture of the technology that is available to support any solution and any gaps.
  • We really appreciate your attendance and participation in this webinar. If you found this to be a valuable experience, please recommend the course to your friends and coworkers!
  • Project Management Overview

    1. 1. International Institute for Learning, Inc. Lone Star Regional Conference Project Management Overview
    2. 3. Projects are Mission Critical <ul><li>PM Project management is a mission critical success </li></ul><ul><li>PM methodology is a means to improve performance </li></ul><ul><li>Effective projects create new products and services </li></ul><ul><li>Implement process and quality improvement </li></ul><ul><li>Lead to complex business development initiatives and sales fulfillment </li></ul><ul><li>Companies equipped with PM accelerates mergers and acquisitions projects </li></ul>
    3. 4. Are People Methodology Averse???? <ul><li>How many of you have had negative </li></ul><ul><li>methodology experiences ? </li></ul>
    4. 5. Are People Methodology Averse??? <ul><li>What are the negative aspects of using </li></ul><ul><li>a methodology? </li></ul><ul><li>How can Program Management methodology </li></ul><ul><li>get in the way? </li></ul><ul><li>What is the relationship between </li></ul><ul><li>methodology and business results? </li></ul>
    5. 6. The Need for PM Methodology <ul><li>Reduces risk of failure </li></ul><ul><li>Increases efficiency and productivity </li></ul><ul><li>Enriches program quality </li></ul><ul><li>Improves communications and knowledge </li></ul><ul><li>Drives organizational change management </li></ul><ul><li>Equips organization with tool for competitive </li></ul><ul><li>advantage </li></ul>
    6. 7. Essential to PM Improvement and Competitive Change
    7. 8. What Is a Methodology? Source: Blais, The Beginning and End of Software Engineering , 2007 <ul><li>A system of: </li></ul><ul><ul><li>Principles </li></ul></ul><ul><ul><li>Practices </li></ul></ul><ul><ul><li>Procedures </li></ul></ul><ul><li>Applies to a specific branch of knowledge </li></ul><ul><li>(Model/Workflow) to achieve an expected </li></ul><ul><li>result </li></ul><ul><li>Guidelines/Framework </li></ul>
    8. 9. <ul><li>PM focuses on project end dates </li></ul><ul><li>Product lifecycle is concerned with longevity of a </li></ul><ul><li>product </li></ul><ul><li>PM focuses on technical details and processes </li></ul><ul><li>Product management is based on competition </li></ul><ul><li>and profitability </li></ul>Differences Between Project Management and Product Lifecycle
    9. 10. Relationship Between PM and Product Lifecycle <ul><li>Product development is headed by a line </li></ul><ul><li>manager </li></ul><ul><li>Heavy involvement of PM in product </li></ul><ul><li>development phase </li></ul><ul><li>Product development processes are mapped </li></ul><ul><li>to PM process </li></ul><ul><li>Product management takes product to market </li></ul><ul><li>after development </li></ul>
    10. 11. Issues Addressed by PM Methodology <ul><li>Late and over budget projects </li></ul><ul><li>Scope creep </li></ul><ul><li>Reporting and control shortfalls </li></ul><ul><li>Multi-project coordination </li></ul><ul><li>Unclear communication </li></ul><ul><li>Runaway projects </li></ul><ul><li>Competency issues </li></ul>
    11. 12. Maturity and Methodology
    12. 13. What Is a Singular Methodology? <ul><li>Does one size fit all? </li></ul><ul><li>Can a methodology be singular and flexible? </li></ul><ul><li>What’s better…. </li></ul><ul><ul><li>Fit the project to the methodology </li></ul></ul><ul><ul><li>Fit the methodology to the project </li></ul></ul><ul><li>A good methodology is…. </li></ul><ul><ul><li>Scalable </li></ul></ul><ul><ul><li>Configurable </li></ul></ul><ul><ul><li>Customizable </li></ul></ul><ul><ul><li>Cost-effective </li></ul></ul>
    13. 14. Small Projects
    14. 16. Source: Leffingwell & Widrig, Managing Software Requirements , Addison Wesley, 2003
    15. 18. Obtaining Buy-In <ul><li>Show results – pilot projects </li></ul><ul><li>Motivate </li></ul><ul><li>Get, acknowledge, and use feedback </li></ul><ul><li>Involve the users in the development and the continuous improvement of the methodology </li></ul>
    16. 19. PM Improvement Strategies/ROI Strategies <ul><li>Manage organizational changes </li></ul><ul><ul><li>Integrates education, sales, coaching, tools, </li></ul></ul><ul><ul><li>monitoring </li></ul></ul><ul><li>Grass roots vs top down </li></ul><ul><ul><li>Autonomy and non-authoritarian </li></ul></ul><ul><ul><li>implementation </li></ul></ul><ul><ul><ul><ul><li>VS </li></ul></ul></ul></ul><ul><ul><li>Mandated compliance </li></ul></ul><ul><li>Goals </li></ul><ul><ul><li>Just enough standardization </li></ul></ul><ul><ul><li>VS </li></ul></ul><ul><ul><li>Total standardization </li></ul></ul>
    17. 20. Sample PM Deployment Strategy IIBA BOK, R 1.4, p. 85-86 <ul><li>Ready the environment for formal PM…. </li></ul><ul><li>Deploy as framework/guideline – make it </li></ul><ul><li>available and they will use it </li></ul><ul><li>Integration with global training initiative </li></ul><ul><li>Coaching </li></ul><ul><ul><li>On-line tools like UPMM have online experts </li></ul></ul><ul><li>Initially no centralized PMO </li></ul><ul><li>Initially no compliance monitoring </li></ul>
    18. 21. Overview <ul><li>Reduces risk of failure </li></ul><ul><li>Increases efficiency and productivity </li></ul><ul><li>Enriches program quality </li></ul><ul><li>Improves communications and knowledge </li></ul><ul><li>Drives organizational change management </li></ul><ul><li>Equips organizations with tools for competitive </li></ul><ul><li>advantage </li></ul>
    19. 24. Evaluations