Systems Development Life Cycle

1. Systems Development Life Cycle • Vision • Strategic direction • Objectives • Results to achieve • Strategy • How vision will be attained • Long-range plans • 3-5 year horizon • Annual plan • Financial plan

2. Architecture • Information systems architecture • Business systems architecture • Technical architecture • Network architecture

3. Policy versus planning • Policy sets criteria for planning • Planning • Done at many levels throughout the organization • From long range to intermediate time horizons • From general to specific

4. Telecom planning • Long range planning—architecture • Mid-level planning—components that fit the architecture • Lower-level planning –configurations, features, procedures and training for specific operations

5. Sources of requests for projects • Telecom group itself • Technical knowledge, often not knowledge of business needs • User groups • Senior managers • Customers/vendors/government agencies

6. Network modeling • Logical • Geographical • System’s design • Data flow or topology

7. Phases of network analysis and design • Problem identification, definition and objective statement • Development team—technical expertise, users, vendors and service providers • Need for a champion • Preliminary determination of requirements • Assessment of risk involved • Deliverable—white paper describing the problem to be solved or the opportunity to be taken advantage of

8. Second step • Preliminary investigation and feasibility study • Technical • Behavioral • Economic –plus/minus 50% cost variance • Operational • Time • Regulatory • Ethical • Deliverable: report of feasibility and preliminary cost estimate

9. Third step • Systems analysis—detailed understanding and definition • Specifications • Prototyping and simulation • Make-or-buy decisions • Architecture • Planning and documentation • Deliverable: specification of requirements, defined strategy and architecture, updated cost estimate, test plans

10. Further steps • Step four: Investigation of alternatives • Deliverable: statements of alternatives available with cost and value of each and recommendation of best alternative • Step five: general network design • Deliverable: diagram showing components of project • Step six: selection of vendor and equipment • Deliverable: rating and ranking of vendors, with recommendations

11. Even more steps • Step seven: calculation of costs • Deliverable: recommendation of final configuration after calculation of costs by alternative vendor • Step eight: presentation to management • Step nine: final decisions and design • Step ten: procurement • Step eleven: preparation for implementation

12. And the final steps • Step twelve: installation of equipment • Step thirteen: system testing • Step fourteen: training • Step fifteen: implementation • Cutover: pilot, parallel, phased, cold turkey • Step sixteen: after implementation cleanup and audit • Step seventeen: system turnover to maintenance

13. “How to fail in project management without really trying” –J.K. Pinto and O.P Kharbanda • Ignore the project environment—including the stakeholders • Push a new technology to market too quickly • Don’t bother building in fallback options • When problems occur, shoot the one most visible • Let new ideas starve to death form inertia—Xerox example • Don’t bother conducting feasibility studies—ready, fire, aim • Never admit a project is a failure • Over-manage project managers and their teams • Never conduct post-failure reviews—insanity= doing the same thing in the same way and expecting a different result • Never bother to understand project trade-offs • Allow political expediency and infighting to dictate crucial project decisions • Make sure the project is run by a weak leader

14. Lessons to be learned • Projects often involve risk and always upset the organizational status quo • Past failures should not discourage future effots

15. Project failure • Not enough resources • Not enough time • Unclear expectations • Necessary changes are not understood or agreed upon by the stakeholders • Disagreements among stakeholders

16. The 12 rules of project management from “The Complete Idiot’s Guide to Project Management” • Thou shalt gain consensus on project outcomes • Thou shalt build the best team you can • Thou shalt develop a comprehensive, viable plan and keep it up to date • Thou shalt determine how much stuff you really need to get things done • Thou shalt have a realistic schedule • Thou won’t try to do more than can be done • Thou will remember that people count • Thou will gain the formal and ongoing support of management and stakeholders • Thou must be willing to change • Thou must keep others informed of what you’re up to • Thou must be willing to try new things • Thou must become a leader

17. Five processes of project managementfrom “The Complete Idiot’s Guide to Project Management” • Project initiating • Project planning • Project executing • Project controlling • Project closing • These embody the three general functions of project management: definition, planning, and control

18. Project initiating process • Recognize that a project needs to be done • Determine what the project should accomplish • Define the overall project goals • Define general expectations of all stakeholders • Define the general project scope • Select initial members of the project team • Write and agree on a statement of work or contract of the project • Establish the rules for the project—levels of authority, communication channels, chain of command

19. Project planning process • Refine the project scope (balance required among results, time, and resources) • List tasks and activities that will lead to achieving the project goals • Sequence activities in most efficient way • Develop a workable schedule and budget • Get the plan agreed to and approved by the stakeholders

20. Project executing process • Procure necessary resources (money, people, equipment, time) • Lead the team • Meet with team members • Secure the special talent and expertise needed • Communicate with stakeholders (ongoing process)

21. Project controlling process • Monitoring deviation form the plan • Take corrective action • Receive and evaluate project change requests from stakeholders and team members • Reschedule project as needed • Adapt resource levels as necessary • Change the project scope • Return to planning stage when necessary to make adjustments to goals and get them approved by stakeholders • Fire-fighting (conflict resolution) to resolve problems

22. Project closing process • Acknowledgement of achievements and results • Shutting down the operation and disbanding the team • Learning from the project experience • Reviewing the project process and its outcomes with team members and stakeholders • Writing a final project report