Systems Development Life Cycle

advertisement
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
Architecture
• Information systems architecture
• Business systems architecture
• Technical architecture
– Network architecture
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
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
Sources of requests for projects
• Telecom group itself
– Technical knowledge, often not knowledge of
business needs
• User groups
• Senior managers
• Customers/vendors/government agencies
Network modeling
•
•
•
•
Logical
Geographical
System’s design
Data flow or topology
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
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
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
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
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
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
“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
Lessons to be learned
• Projects often involve risk and always
upset the organizational status quo
• Past failures should not discourage future
effots
Project failure
• Not enough resources
• Not enough time
• Unclear expectations
– Necessary changes are not understood or
agreed upon by the stakeholders
– Disagreements among stakeholders
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
Five processes of project management
from “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
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
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
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)
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
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
Download