Projektu vadība
•
1 gostou•4,686 visualizações
Tikko uzgāju Projektu vadības prezentāciju, kuru ap 2007.gadu gatavoju CMC sertifikācijas programmai. Neiedziļinoties detaļās, sertifikācijas process mainīja formātu un šī prezentācija vairs nebija vajadzīga. Mūsdienās pastāv uzskats, ka projektu vadība nozīmē dabūt naudu un pareizi rakstīt atskaites, lai tā nauda nav jādod atpakaļ. Ja vēlies lejuplādējamu versiju ar animācijām un slaidu komentāriem, tad sazinies ar mani
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Projektu vadība
Semelhante a Projektu vadība (20)
Projektu vadība
- 1. Projektu vadība Copyright (c) 2008 by Edmunds Šuļžanoks. This work is licensed under the Creative Commons Atsaucoties-Nekomerciāls-Nemainīts 3.0 Nepārnesta License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-nd/3.0/.
- 2. Satura rādītājs Projektu vadības pamatjēdzieni Iniciēšana Plānošana Izpilde Monitorings un kontrole Slēgšana Komandas līderība (nav iekļauts)
- 4. Projekts - laikā ierobežota iniciatīva unikāla rezultāta izveidošanai Projektu vadība - zināšanu, spēju, rīku un paņēmienu pielietošana aktivitāšu virzīšanai, lai izpildītu projekta prasības Projekta vadība ietver Prasību identificēšanu Skaidru un sasniedzamu mērķu nospraušanu Savstarpēji konkurējošo zemu izmaksu, augstas kvalitātes un īsā laika prasību balansēšanu Specifikāciju, plānu un pieeju adaptēšana dažādu ieinteresēto pušu atšķirīgām prasībām Source: A Guide To Project Management Body Of Knowledge, 3rd edition
- 5. Klasiskie projektu vadības ierobežojumi Nauda / Lēti Izvēlies jebkurus divus! Laiks / Ātri Kvalitāte / Labi
- 6. Projekta vadītāja loma A manager's job is to get things done by other people Atbildīgais par projekta mērķu izpildi Projekta komandas vadītājs (līderis + administrators) Resursu un darbu orķestrētājs Konfliktu risinātājs / izšķīrējs Konfliktējošu prasību saskaņošana
- 7. Citas ieinteresētās puses Klients / lietotājs (daudzas apakšgrupas) Izpildošā organizācija Projekta komandas locekļi Projekta vadības komanda Sponsors Ietekmējošie Daudzi citi 7
- 8. Ieinteresēto pušu vadība Iesaisti, lai radītu Jāstrādā kopā, Augsta interesi un lai sasniegtu ietekme apņemšanos vairāk Kur vien Zema Komunicē, lai tie iespējams, ietekme justos iesaistīti iesaisti, lai tie justos nozīmīgi Zema interese Augsta interese 8
- 9. Atklātās un apslēptās prasības Atklātās prasības Apslēptās prasības Samazināt Lielākas algas izmaksas Darbinieki vēlas Organizācija vēlas saglabāt darbu samazināt štatu Lietotāju vadītājs Projekta līderis vēlas darbības vēlas pilnīgu testu nepārtrauktību
- 10. Laiks, izmaiņas, izmaksas Ideālā situācija Augsts Ieinteresēto pušu aktivitāte Izmaiņu izmaksas Zems Laiks 10
- 11. Laiks, izmaiņas, izmaksas Nevēlamā situācija Augsts Ieinteresēto pušu aktivitāte Izmaiņu izmaksas Zems Laiks
- 12. Projekta dzīves cikls Projekta sākums Projekta beigas INITIAL I N T E R M E D I A T E FINAL Projekta dzīves cikls definē fāzes , kas savieno projekta sākumu ar tā beigām
- 13. Projekta dzīves cikls programmatūras izstrādei izmantojot 4GL (Piemērs) Projekta sākums Projekta beigas Analysis Design Transition Build & Strategy Document
- 14. Projekta dzīves cikls – Decision- Support Applications (Piemērs) Projekta sākums Projekta beigas Planning Design Deployment Business Justification Construction Analysis
- 15. Dažādu projektu dzīves ciklu kopīgās iezīmes Personāla skaits un izmaksas sākumā ir mazas, sasniedz smaili vidus fāzēs un strauji krīt noslēguma fāzē Lielākās neskaidrības un risks nesasniegt projekta mērķus ir projekta sākumā. Izmaiņu veikšana un kļūdu labošana sākumā ir salīdzinoši lēta, projektam progresējot tā kļūst dārgāka Ieinteresēto pušu spēja ietekmēt projektu ir augstāka projekta sākumā un projektam progresējot pamazām krīt Ieinteresēto pušu vēlme projekta sākumā ir diezgan zema, tuvojoties projekta noslēgumam tā strauji kāpj
- 16. Phase - Gate - Phase - Gate (Go/Kill/Redo)
- 17. Projektu vadības procesu grupas Uzraudzība un kontrole Iniciēšana Slēgšana Ideja Produkts
- 18. Definē projektu vai projekta fāzi un autorizē tās sākumu INICIĒŠANA
- 19. How IT Projects really work (www.projectcartoon.com) Kā klients izskaidroja... Ko klientam tiešām vajag... Klients bieži runā par risinājumu, nevis tā vajadzību Iedomātais risinājums, bieži neatrisina biznesa vajadzību Pasūtījuma izpilde ir Projektu vadītāja, nevis klienta kļūda
- 20. Procesu karte Variants “A” Variants “B” Variants “C” Background Background Background izpēte izpēte izpēte Project Charter Kick-Off Dev & Sign-off Project Charter Kick-Off Dev. & Sign-off Project Charter Kick-Off Dev. & Sign-off Plānošana Plānošana Plānošana
- 21. Projekta vides izpratne Organizācijas stratēģija Organizācijas kultūra un struktūra Infrastruktūra Cilvēkresursi Personāla vadības vadlīnijas Darbu un pārmaiņu autorizēšanas sistēma Tirgus situācija Aplikācijas un datu bāzes (t.sk. Finanšu, risku, projektu vadības, info apmaiņas utt.) Source: PMBOK 3rd edition
- 22. Projekta definīcija (Project Charter) Biznesa prasības / mērķi / nepieciešamības pamatojums Sfēra / Piegādes Pieņemšanas kritēriji Panākumu faktori Ierobežojumi Pieeja Lomas un organizatoriskā struktūra Procedūras & standarti
- 23. S.M.A.R.T. mērķi S - Specific (short, simple) M - Measurable A - Agreed R - Realistic T - Time-bound
- 24. Kick-off Projekta uzsākšanas pasākums, ko veic ar mērķi: Radīt vienotu izpratni projekta mērķiem Team building Generate buy-in – iesaistīt dalībniekus projekta vadības komandā – uzlādēt ar enerģiju darbam Radīt skaidru redzējumu par katra dalībnieka lomu un artavu projekta mērķu izpildē
- 25. Atbilstoši uzdevumam, uzstāda mērķus, plāno resursus un aktivitātes šo mērķu izpildei PLĀNOŠANA
- 26. Procesa karte Iniciēšana A B Projekta plāna Activity list Schedule izstrāde WBS + Activity Cost vārdnīcas resource estimating & izstrāde estimating bugeting Risku Kvalitātes Activity Izpilde vadības plāns vadības plāns Duration vai estimating Slēgšana A B
- 27. Projekta vadības plāns Definē kā projekts tiks plānots, izpildīts un kontrolēts. Saturs variē no atkarībā projekta sarežģītības pakāpes un sfēras: Izvēlētie procesi, procesu karte, to ieviešanas pakāpe, rīki un paņēmieni, inputs & outputs Kā notiks versiju kontrole, kā izmaiņas tiks vadītas Lomas, organizatoriskā struktūra, pilnvaras uzņemties saistības, pieņemt lēmumus un apstiprināt izmaiņas Nepieciešamās komunikācijas, kanāli, rīki un paņēmieni Plāns nav kalendārais grafiks – Grafiks ir aktivitāšu saraksts – Plāns ir izvēlētais ceļš uz mērķiem Plāni mainās!
- 28. Struktūrplāns (WBS) + WBS vārdnīca Hierarhiski strukturēta un uz piegādēm orientēta, darbu dekompozīcija, kas projekta komandai ir jāizpilda, lai sasniegtu projekta mērķus un radītu nepieciešamās piegādes 100% project scope 1 WBS code “Better CRM” 100% node scope 1.1 1.2 1.3 1.4 Require- Soft + Fully Design user doc. ments working 1.1.1 1.2.1 1.3.1 1.4.1 Darbu 1.1.2 1.2.2 1.3.2 1.4.2 paka 1.1.3 1.2.3 1.3.3 1.4.3 100% node scope 1.1.4 1.2.4 1.3.4 1.4.4 1.1.4.1 1.1.4.2
- 29. Rolling wave plan Progresējoša plāna detalizācijas metode, kas paredz sīku tuvo fāžu detalizāciju, kamēr tālākās fāzes paliek diezgan augstā detalizācijas līmenī Detalizācijas “Better pakālpe CRM” Transiti Analysis Design Build on Projekta progress
- 30. Riska varbūtības un ietekmes matrica Riska reitings Draudi Iespējas Iestāšanās varbūtība 0.90 0.05 0.09 0.18 0.36 0.72 0.72 0.36 0.18 0.09 0.05 0.70 0.04 0.07 0.14 0.28 0.56 0.56 0.28 0.14 0.07 0.04 0.50 0.03 0.05 0.10 0.20 0.40 0.40 0.20 0.10 0.05 0.03 0.30 0.02 0.03 0.06 0.12 0.24 0.24 0.12 0.06 0.03 0.02 0.10 0.01 0.01 0.02 0.04 0.08 0.08 0.04 0.02 0.01 0.01 0.05 0.10 0.20 0.40 0.80 0.80 0.40 0.20 0.10 0.05 Negatīva ietekme uz mērķiem Pozitīva ietekme uz mērķiem
- 31. Risku vadības plāns Risku dzīves cikls Ko dara ar riskiem? Indentificē Novērtē Vada Uzrauga Ziņo Tolerate Treat R10: We plan for and design the wrong functionality and services because we don’t get enough end-user – Mīkstināt ietekmi feedback Affect Quality Time Cost Scope – Samzināt WBS code: 1.3 varbūtību Probability High Medium Low Transfer Impact Minimal Average Severe – Insurance Level of control High Medium Low – Outsource Management strategy Validate results with partnership subject matter results (WBS code: 1.3.7) Validate results with other published surveys, Terminate research and documents (WBS code: 1.3.7) Responsibility: Mike
- 32. Kvalitātes vadības plāns Kvalitātes vadības plāns ir Projekta vadības plāna sadaļa vai tā apakšplāns, kas skaidro, kur, kad un kādi procesi, rīki un paņēmieni tiks piemēroti, lai sasniegtu kvalitātes mērķus Ekspektāciju vadība Kā panākt to, lai tas ko Nepasaka klients mēs darīsim sakristu ar klientu cerībām Kādas kvalitātes prasības C pret piegādēm R e e Cik kritiskas ir šīs Pasaka klients prasības z r Kas šīs prasības izvirzīja u ī Kvalitāte ir pakāpe, kādā Procesi, rīki un paņēmieni l b tiek īstenotas kvalitātes nodrošināšanai t a dokumentētās un Kad jāveic kvalitātes iedomātās prasības ā s Pasaka projekta kontrole, rīki un paņēmieni konkrētā vietā t vadītājs s Kvalitātes vadība
- 33. Aktivitāšu detalizēšana Konceptuāli Sākotnējais plāns Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Detaļas Laiks Source: Project Management and Team Leading, Bill Peters, Straightforward training
- 34. Paņēmieni darbietilpības novērtēšanai Eksperta spriedums Vēsturiskie dati Formula
- 35. Stage ratio Strategy 9% 33 cilvēkdienas Analysis 18% 66 cilvēkdienas Design 12% 44 cilvēkdienas Build & 38% 139 cilvēkdienas Document Transition 23% 84 cilvēkdienas 366 dienas Basic estimate Source: Project Management and Team Leading, Bill Peters, Straightforward training
- 36. Basic estimate A (366d) +1 diena pie Contingency Strategy fāzes Lost time + 20% - Hard (+10%) 4 day week - Soft (+20%) +67 dienas pie (209 dienas) pārējām fāzēm Overheads Act of God - Management (+15%) - Meetings (+5%) Contingency + 20% Workload estimate 229 dienas (523d) (Projekta kopējais ilgums) Performance factor - Trainee (0,5) - Junior (0,67) - Standart (1) - Experianced (1.5) - Senior (2.0) 3 [523 / 3 = 175] A Source: Project Management and Team Leading, Bill Peters, Straightforward training (Team factor)
- 37. Activity Sequencing B B A A D A D B C C C D A A A B B B C C C D D D
- 38. Aktivitāšu savienojumi Finish Start Start Start Finish Start Finish Finish
- 39. Šādi nesavienot!
- 40. Gantt Chart
- 41. Integrē cilvēkus un citus resursus projekta plāna izpildei IZPILDE
- 42. Procesa karte Plānošana A DP izpilde un progresa RFC kontrole Darbu Pakas B RFC C (DP) izstrāde Nodevumu kvalitātes kontrole DP validēšana Darbu pakas C B slēgšana RFC RFC Uzraudzība Plānošana Slēgšana A un kontrole
- 43. Darbu pakas apraksts Projekta nosaukums: Projekta Nr. DP nosaukums: WBS code: DP vadītājs: DARBU PAKAS UZDEVUMU APRAKSTS Uzdevuma nosaukums Sākums Beigas Darba pakas izpildes termiņi: DP izpildei nepieciešamie resursi Īpašnieks DP rezultāti: __________________ __________________ DP vadītājs _ Projekta vadītājs _ (Parakst, datums) (Parakst, datums)
- 44. Kvalitātes kontrole ■ Rīki un paņēmieni Cause and effect diagram ■ Run chart & Control chart ■ Flowchart Histogram & Pareto Chart Scatter diagram Check-list Audit & Inspection Structured walkthrough & Fagan Inspection Statistical sampling
- 45. Prasību verificēšana Allocatable Attainable Complete Consistent Correct Does Not Prematurely Determine Solution Feasible Measurable and Testable Necessary Prioritized Traceble Unambiguous Understandable Verifiable Source: Business Analysis Body of Knowledge v1.6
- 46. Regulāri mēra un uzrauga progresu, lai identificētu novirzes no projekta vadības plāna un savlaicīgi izpildītu nepieciešamās korektīvās darbības UZRAUDZĪBA UN KONTROLE
- 47. Procesu karte Projekta plāna, bāzlīniju un robežstabu parakstīšana Grafika, sfēras, risku, kvalitātes, budžeta uzraudzība – Regulāra – Noteiktos posmos – Fāžu noslēgumos Problēmu vadība Izmaiņu kontrole
- 48. Paraksta spēks Formalizē vienošanos Prasa apņemšanos Liek izlasīt Prasa kontaktu Nozīmē - pabeigta versija
- 49. Atslēgas dokumenti Project charter Project m’g’t plan Risk management plan Quality management plan WBS + WBS dictionary Schedule + resource plan Budget Darba pakas Prasības Specifikācijas Akcepttestu protokoli Protokoli
- 50. “V” modelis Biznesa prasības Akcepttesti Augsta līmeņa projektējums Sistēmas testi Detalizēts projektējums Integrācijas testi Sistēmas kods Vienību testi
- 52. Schedule network analysis Kritiskā ceļa izpratne Early Early finish start date date (Early) start + duration Task 0 3 -------------------- name = Early finish A3 0 0 3 (Late) finish - duration Late -------------------- start Duration = Late start date Float Late finish date
- 53. Schedule network analysis Kritiskā ceļa izpratne FORWARD PASS (EARLY DATES) - LIELĀKAIS DIENU SKAITS 3 5 5 10 10 15 Free float B2 D5 G5 3 0 5 510 vai 12?12 2 17 0 10 0 3 9 vai 10?17 10 17 20 Tied float A3 H7 I 3 0 0 3 10 0 17 17 0 20 3 6 6 9 C3 F3 Critical path 4 1 7 7 1 10 BACKWARD PASS (LATE DATES) – Mazākais dienu skaits
- 54. Izmaiņu vadības process Projekta Definīcija (Charter) Proj.vad.plāns Risku vadības plāns Kvalitātes vadības plāns WBS + WBS vārdnīca Kalendārais grafiks resursu plāns Budžets Darba pakas Prasības Specifikācijas Akcepttestu protokoli Protokoli
- 55. Izmaiņu vadības noteikumi (o) – obligāts; (v) - vēlams Ja izmaiņas netiks vadītas, projekts izgāzīsies Izmaiņas apstiprina – Projekta valde vai Izmaiņu valde – Projekta vadītājs (izmaiņu ietvaros) Izvērtē visas izmaiņas ietekmes Nespamo projekta valdi par nelielām izmaiņām lem pats Visiem izmaiņu pieprasījumiem ir jābūt izdarītiem rakstiskā formā Visus izmaiņu pieprasījumus fiksē žurnālā (pieprasītājs, apraksts, ietekmes, pamatojums, datumi, statuss) Nepieņem, ka izmaiņas tiks apstiprinātas Neliec komandai gaidīt, izmaiņas ierosini nekavējoties Don’t cut corners – neatvieglo dzīvi uz “sīkumiem” Komunicē visas izmaiņas
- 56. Formalizē produkta pieņemšanu/nodošanu, pārtrauc visas aktivitātes un saistības, projektam piešķirtos resursus atdod to īpašniekiem SLĒGŠANA
- 57. Procesu karte Uzraudzība Plānošana Izpilde A un kontrole Check-list Exercise sagatavošana review/Lessons learned Pārtraukt līgumus un procesus Projekta dokumentācija Atdot s sapakošana resursus un produktus Formāla projekta A slēgšana
- 58. Retrospektīvas sanāksmes Projekta grupas Kas retrospektīvas periodā izdevās labi Ko var uzlabot? Kā atkārtot panākumus turpmākajos projektos? Personīgās Personīgās stiprās puses? Ar kādiem šķēršļiem saskāries? – Kā tie ietekmēja Tabu darbu? – Kā tos pārvarēt un uzlabot izpildi?
- 59. Lessons Learned Mērķis: Veicināt sekmīgi sasniegtu rezultātu atkārtošanos un Izvairīties no atkārtotām kļūdām Gūtās mācības un Izplatīšana Apkopošana labās prakses Atkārtota izmantošana Gūtās mācības un Gūto mācību un labās prakses Zināšanu labo prakšu apkop. pielietošana Nozīmīgs Derīgs Saglabāt Pielietojams Pielietojamības Verificēšana Uzticams avots pārskats Svaigs Atkārtojams Darbības Uzlabošanas Politikas Procedūras iespēja
Notas do Editor
- Atbildīgais par projektu mērķu izpildi - The project leader must assume responsibility for all aspects ofthe project. If something goes wrong it is the project leader who takes the blame. Ifsomething needs doing, it is the project leader who ensures that it is done. /BillPeters/Kāpēc projektu vadītājs apņemas vadīt projektu? Vai viņš vēlas slavu? Mierīgu dzīvi? Jaunas zināšanas? Karjeras izaugsmi? Lai, kas tas arī būtu arī viņš ir klients ar savu interesi - ieinteresētā puse.
- The project life cycle defines the phases that connect the beginning of a project to its end. For example, when an organization identifies an opportunity to which it would like to respond, it will often authorize a feasibility study to decide whether it should undertake the project. The project life cycle definition can help the project manager clarify whether to treat the feasibility study as the first project phase or as a separate, stand-alone project. Where the outcome of such a preliminary effort is not clearly identifiable, it is best to treat such efforts as a separate project. The phases of a project life cycle are not the same as the Project Management Process GroupsThere is no single best way to define an ideal project life cycle. Some organizations have established policies that standardize all projects with a single life cycle, while others allow the project management team to choose the most appropriate life cycle for the team’s project. Further, industry common practices will often lead to the use of a preferred life cycle within that industry.
- The transition from one phase to another within a project’s life cycle generally involves, and is usually defined by, some form of technical transfer or handoff. Deliverables from one phase are usually reviewed for completeness and accuracy and approved before work starts on the next phase. However, it is not uncommon for a phase to begin prior to the approval of the previous phase’s deliverables, when the risks involved are deemed acceptable. This practice of overlapping phases, normally done in sequence, is an example of the application of the schedule compression technique called fast tracking.
- Does Not Prematurely Determine Solution - The requirement should be stated in a way to allow the widest possible election of implementation options.
- Aplikācijas un datu bāzes, kuras var nākties lietot projekta laikā.
- Galvenais ierocis projektu vadītāja arsenālā
- Takeaway: Your team's first impression of a project can set the tone for success or failure. These planning guidelines will help you make your project kickoff meeting count.Your first project meeting is an opportunity to share your plan for leading the project to a successful completion. You should take advantage of this one-time chance to energize the group, set proper expectations, and establish guidelines that will help you complete the project on time and within budget. If you fail to prepare for this meeting, you’ll put the project at risk right from the start.When you leave the kickoff meeting, everyone on the project team must be on the same page. Your preparation beforehand will determine whether your kickoff meeting will offer the greatest benefit to team members.Meeting preparationStep 1: Develop the project goals and deliverablesDefining these elements will drive the decisions you must make for staffing the project and developing the project plan. Write them down and validate your definitions with the project owners (whoever justified and initiated the project).Step 2: Identify the project team members and their responsibilitiesResource needs vary based upon the size, complexity, and nature of the project. Include resources from four key groups, as needed, to fully support your project.Operations Corporate support Management TechnicalDevelop a project team contact list that includes the name, responsibility, department, physical location, phone number, fax number, and e-mail address for each member. You’ll want to distribute this to the team.Step 3: Develop a project assumptions listIt’s important for project team members to be aware of major assumptions that apply to the project. For example, spell out the assumption that each team member has been selected and made available to the project by their manager to ensure its success. That assumption means that their assigned tasks must take priority, and each participant must be committed to the success of the project if they are to participate.Step 4: Develop the preliminary project planYou can save a lot of time by going ahead and developing the tasks, responsibilities, and timeframes of the project plan. Going through this exercise will help you validate whether you have the right resources, identify risks, and determine the appropriate timelines for tasks and milestones.Use whatever resources you need to help you create the initial project plan. The point here is that when you go into the kickoff meeting, you will already have a plan drafted. Doing so will save time and get the project off to a faster start. (To develop a project plan, download this project-planning template.)Realize that the plan is not carved in stone at this point. Actually, it should never be. Up until the kickoff meeting, it is a knowledgeable draft. Once you have the team assembled and assign clear responsibilities, you should ask team members to validate their task responsibilities and timeframes for reasonability, completeness, and accuracy. The plan will become more established at the first project status meeting.Step 5: Define key success factorsEvery project team member needs to know what it takes to have a successful project. Take the time to define in specific terms each item that will be required for success. Validate your list with the project owner(s).Step 6: Schedule the project kickoff meetingIt is important for all project team members to participate in the kickoff meeting. Send a communication to each participant with a preferred time and date and include options in case they are unavailable. Even if someone is “out of pocket,” he or she can participate by phone.Your goal here is to assemble the entire team so they all hear the same message at the start of the project. Instruct all participants to look for meeting materials on a specified date and to prepare for the meeting by reviewing them.As soon as you have a firm time and date, schedule a conference room and phone services to support conference calls, as needed. Plan for a 90-minute meeting.Personal noteIn a recent project, I had 12 team members from four company departments located in seven physical office locations in five cities. It’s not always feasible to get all team members in the same conference room, as in this case. By preparing a solid agenda, providing supporting documentation ahead of time, and organizing the flow of the meeting, you can conduct an excellent kickoff meeting that gets all participants focused on the same objectives, even when many do not know one another. Step 7: Send the kickoff meeting materials to all participantsOn your designated date, send a package of meeting materials to each participant, including:Meeting time and date with call-in phone number Meeting agenda Project participants’ contact information Project plan draftAsk each person to review the project plan carefully. Indicate that additional information will be discussed at the kickoff meeting and everyone should be familiar with his or her part of the plan. Explain that there will be a Q&A session at the meeting to answer any questions.Step 8: Identify key issues and project dependenciesReview the project plan prior to the kickoff meeting and make notes on points that you want to make at the meeting. Pertinent items include potential bottlenecks, impact issues, risk areas, etc.What's next?After all of your preparation, knowing how to conduct your kickoff meeting is the next step. In part two of this series, we’ll detail the best way to lead a project kickoff meeting.
- The 100% Rule- WBS includes 100% of the work defined by the project scope and captures all deliverables. The 100% rule is one of the most important principles guiding the development, decomposition and evaluation of the WBS. The rule applies at all levels within the hierarchy: the sum of the work at the “child” level must equal 100% of the work represented by the “parent” and the WBS should not include any work that falls outside the actual scope of the project, that is, it cannot include more than 100% of the work
- Allocatable - The requirement can be allocated to an element of the system design where it can be implemented.Attainable - Attainable means that the requirement is technically feasible and fits within the project funding and timing constraints. Even if a requirement is technically feasible, it may not be attainable due to constraints, e.g., weight or speed.Complete - To be complete, all known requirements are documented and all conditions under which a requirement applies are stated. Each requirement must contain all the information necessary for the technical team to design, build and test that component of the system.Consistent - Consistency demands that the requirement can be met without causing conflict with any of the other requirements.Correct - Each requirement must accurately describe the functionality to be built. Only the customer, user or stakeholder who was the source of the requirement can determine its correctnessDoes Not Prematurely Determine Solution - The requirement should be stated in a way to allow the widest possible election of implementation options.Feasible - Feasible means that it is possible to implement each requirement within the capabilities and limitations of the technical and operational environment.Measurable and Testable - Requirements that are testable are designed to demonstrate that the system satisfies requirements. Tests may include functional, performance, regression, and stress tests.Necessary - A necessary requirement is one that is essential to meet the business goals and objectives. If the system can meet prioritized, real needs without it, the requirement is not necessary. The requirement should be traceable to a goal stated in the project charter, vision document, business case, or other initiating document.Prioritized - A priority is assigned to each functional requirement or feature to indicate how essential it is to a particular system release. If all requirements are considered equally important, it is difficult for the Business Analyst and the Project Manager to respond to budget cuts, schedule overruns, staff turnover or new requirements added during development.Traceable - The origin (source) of the requirement must be known, and the requirement can be referenced or located throughout the system. (Note: an automated requirements traceability tool enables finding the location in the system where each requirement is met.)Traceable backwards: each requirement should be traced back to specific customer, user or stakeholder input, such as a use case, a business rule, or some other origin.Traceable forward: each requirement should have a unique identifier that assists in identifying, maintaining change history, and tracing the requirement through the system components.Unambiguous - To be unambiguous, all readers of a requirement should arrive at the same interpretation of its meaning. Requirements that are written in simple, concise, straightforward language are more likely to be unambiguous. All specialized terms and terms that might be subject to confusion should be well defined.Understandable - Understandable means that the requirements must be clear, concise, simple and free from ambiguity. Ambiguous requirements are often misunderstood, resulting in rework and corrective actions during the design, development and testing phases. If the requirement can be interpreted in more than one way, it should be removed or clarified.When writing requirements, the author should use simple, short sentences and imperative phrases using shall. Statements indicating goals or using the word will are not imperatives.Verifiable - Verifiable means that the requirement states something that can be confirmed by examination, analysis, test, or demonstration. A good requirement does not contain words that are not testable and measurable. If it is impossible to ensure that the requirement is met in the system, it should be removed or revised. The verification method and level (i.e., the location in the system where the requirement is met) at which the requirement can be verified should be determined explicitly as part of the development of each requirement. Requirement statements that include words that have relative meaning are not verifiable. For example:EasyMaximumMinimumBetter thanAdequateSubstantialQuality productComparisonMore efficient