Unit 4 Development Project Controls and Organization

1

• Unit 4 Development Project Controls and
  Organization
• Explain specific controls in the IT department
  and projects and why they are important
• Overcome or avoid obstacles that get in the way
  of your project proceeding as planned

2

• Management Communications
• Maintain regular contact with senior
• management in IT and user area
•  
• Scope Creep Users want more functionality
• than originally planned
• Requires more time or more staff/budget
• Prepare change request forms negotiate
• Be sure to add to your schedule at critical
  points
• Feature freeze no more new features
• Code freeze nothing but bug fixes 

3
 
 

• Management Controls
• Project Plans
• Detailed plans for each project breaking out
  human resource and software/hardware/network
  costs
• Specific milestones agreed to by management
• Long projects broken down into manageable releases

4
 
 

• Management Controls
• Applications Maintenance Committees
•  
• Purpose System Release Planning and Approval
  across company
• Run by users with IT assistance
• Review projects (made up of bug fixes or change
  Requests) to make changes to existing systems
• Set of prioritized changes authorized by
  responsible department management
• Committee determines whether any resources will
  be given for each project, and then determines
  the cutoff on list of changes for each proposed
  project

5
 
 

• Management Controls
• Applications Committee or Project Steering
  Committee (once project approved and started)
• Regular project review meetings status on
  project (schedule, costs)
• Deal with project issues/make decisions
• Review Project Change Requests (already estimated
  by IT project team
• Prioritise requests
• Approve all changes, and impacts on project plan
• Approve acceptance test plan and regression test
  plan
• Approve promotion of code to production
• NB IT Development department makes changes to
  code
• User sign off on acceptance test
• IT Operations moves changes to production

6

• Be ready for change - adjust the project as you
  go
•  
• Be informed of changes and issues in the users
  work environment
• Consult users on every document, decisions, steps
  in processes, tools, and procedures
• Better to over-invite participation than leave
  out key players
• Nurture your relationship with the client this
  ensures support throughout project 

7

• More change
•  
• Departments can be reorganized
• People quit or new people are hired
• Be prepared for mergers, acquisitions,
  divestitures
•  
• Impact on Project
• Change in business functions and processes
• Changes in political landscape
• New or different technologies
• Impact on budgets 

8

• Project Status Updates
•  
• Report to your client or Steering Committee
• Features implemented
• Features working on
• Problems the team has encountered
• Open issues requiring resolution
• Evolution of documentation training
• Actual spending versus budget
• Actual plan versus estimates

9

• Status Updates (continued)
• Report to your management (IT)
• Detailed design specs
• Building of program modules
• System and test documentation
• Open technical issues requiring resolution
• Statistics on product behaviour at testing
• Deployment plans
• Actual spending versus budget
• Actual plan versus estimates 

10
 
 

• Project Controls Your Turn/Small groups
• 5 minutes
• Each group gets two controls
• Define what each is/what it means (if not
  apparent).
• What could happen without this control?

11
 
 

• Project Controls
• Accounting and audit involvement
• Approved budget
• Available resources
• Documented standards SDLC (Systems Development
  Life Cycle), database standards, programming
  standards, testing standards, documentation
  standards
• Phased Implementations (chunk large projects into
  smaller mini projects Phase I, II, etc.)
• Post implementation review

12
 
 

• Project Controls
• Reports to Steering Committee
• User IT management joint responsibility and
  support
• Experienced project manager
• Project Status Reports time, cost, quality and
  scope
• Experience and breadth of team members
• User involvement in all phases

13
 
 

• Development Controls
• Users and IT jointly responsible for (Why
  Joint?)
• Project plan and scope control
• Requirement specification
• Design specification approval
• User documentation
• Acceptance test plan
• Post Implementation Reviews
• Success/failure of project
• Initial investigation/feasibility
• Cost/benefit analysis

14
 
 

• Development Controls
• IT responsible for
• Design specification
• Applications coding
• Implementing processing controls such as edit
  checks
• Unit and integration testing
• Operations documentation
• Source library controls (version control)

15
 
 

• Development Controls
• Users responsible for
• Communicating business knowledge/system
  requirements and business rules
• Conduct acceptance testing
• Sign off on all deliverables

16

• Outsourcing (Hiring outside help)
•  
• Consultants for expertise
• Contractors for extra labour
•  
• Contract Involves
• Setting scope and deliverables
• Your acceptance criteria
• The project plan/timeframe for completion
• Dependencies on others activities
• Required documentation 

17

• Managing Conflicts
• Process Workflow, communications, issues
• Configuration Shared infrastructure changes,
  such as desktop software or database imposed by
  other teams
• Data Ownership Shared data update rights
•  
• Steps to Take
• Negotiate, then escalate
• Report the problem immediately with impact
  assessment on your project

18

• Documentation Library
• A central repository of all the documents of your
  project
• Accessible by all 
• Organize in separate folders (subdirectories) for
  each type
• project documentation
• system documentation
• test documentation
• user documentation
• Keep up to date and organized
• Assign a team member to co-ordinate and create
  standards for its structure 
• Write procedures on how to create and update the
  documentation

19

• Version Control System
•  
• Automated library of source code, test data,
  documentation
• Define version/build naming convention e.g
  Version 2.1 Build 001
• Maintenance has its own database, front end
  application, and administration
•  
• Development environment platform and coding
  language will influence choice of version control
  system
•  
• Performance must be fast
•  
• Procedures rules required for file sharing,
  checkout

20

• Configuration Management  
• Recommended and tested platforms product will
  operate on an agreed-on number of supported
  machines and versions
• Development platform try and keep the standard
  desktop image document any extra utility tools
• Production environment
• stay informed of every change to the production
  environment
• plan and test changes in test environment, using
  production and development versions

21

• Change Management
• Manage change requests coming from users, your
  team, and QA
•   
• Workflow of a Change Request
• new, evaluation, verification, research,
  submitted for development, accepted for
  development, submitted for testing, accepted for
  testing, being tested, change failed or verified,
  approved for release. 

22
Change Management (cont)   Change Management
Tool ideally integrated with other development
and help desk tools.   Change Issues user
participation (licensing issues), filtering
(clutter), privacy of QA testing, discussion
forums (required for consensus), administration,
ownership, secrecy, use for performance
evaluations, and politics.