Three Tips to Idenity Project and Program Risks

Technology Project and Program Management

I was reading another article about identifying or handling project risks:

http://www.techrepublic.com/blog/five-tips/five-tips-for-handling-project-risks/534?tag=mantle_skin;content

Although it seems to be presenting activities of risk identification and management, and not tips, it was interesting.

But I would like to present three tips to identify project and program risks

 
Three tips (perspectives) to identify/uncover risks for IT projects and programs.

Identify possible/potential risks based on:

1. The technology being developed and introduced to the organization and user community, impact on the organization, other processes (or systems and their interfaces) and people
2. The project or program scope, its approved budget(s), the project plan and schedules, resources (manpower, money, equipment, etc), procurement and subcontractors/vendors
3. The System/System Development Life Cycle (SDLC) i.e., requirements identification and analysis, Architecture/Detail Design, Development, System Test, Delivery/Deployment)

 

Empower and Develop your Project Team/Team Members

Technology Project Management

 

• Ensure open communication takes place (respect members’ expertise and opinions)
• Request and receive team members’ input and buy-in for plans, schedules, risks, etc.
• Allow team members to accomplish their responsibilities and provide any lessons learned without over supervising or micro-managing, unless required.
• Alternate some team members as the team lead (Alternate each member as a team lead and encourage some members to try it if they didn't want to (In these cases if it was not working out, make the an appropriate change)
• Pair novice/inexperienced members with more experienced members
• Acknowledge and recognize team members/team accomplishments and achievements. Ensure recognition is shared with team member’s management in a matrix environment.
• When training opportunities are available make arrangements for attendance by a team member(s) if there are no issues with a member(s) attending the training session. In some cases set up evening training sessions which sometimes may be conducted by an experienced business or technical team member.

 

Technology Project Management Best Practices for Lessons Learned

Technology Project Management

Recently I read this article that grabbed my attention: Stop with the Lessons Learned

 

You would have thought that it was about not doing lessons learned but it was not. It was about documenting and conducting a lessons learned session "post mortem". Although it was a positive article, I applied comments to it because documenting  lessons learned is an important activity and should not just be left for project close out (at the end of a project). Lessons Learned must be documented and used throughout the project and program.Lessons Learned must be used for future projects and programs and during the ongoing, or current, project or program.

Read>> Importance of Documenting Lessons Learned In Technology Projects

 

IT Best Practice Processes

Technology Project Management

Best Practice Processes and their BEST (and Good) Practices

ITBest Practice Processes (BPPs): Project/Program Management, the Development Process (Methodology), Configuration Management, and Quality Assurance. Program/Project Managers (IT Program/Project Management) must plan and implement best Practice Processes (BPPs) and their best and good practices (Read Best Practices Here...). Let’s consider each and what they do for a project or program, why they are essential to plan and implement for each and every project and program. Tailor BPPs as required based on the solution, approach and the development methodology (ies) to be used.

Collaborate! IT and Business Projects and Programs Management, Sales, Contract Management and IT/Technology organizations

Technology Project Management

IT and Business Projects and Programs Management, Sales, Contract Management and IT/Technology organizations must collaborate!

I worked during my career for a company that required just that kind of collaboration and developed an engagement manual/document that presented the policy, process and activities to ensure/enforce (respsonsibilities and accountabilities) the collobration leading to realistic and coordinated projects and programs.

Sales and Technology Departments or groups must collaborate and work up front together (collaborate), as required, before contract award and throughout the contract award process. This process would ensure that Sales and Contract Management/Administration get it right (cost/price for projects/programs) because the Technology organization understands and knows that they have to provide to the sales and contract process realistic data first. This technical and cost information is provided to Sales and Contracts with min and max cost and not just a financial cost (not realistic) that is detrimental to the achievement of the business/company busines plan/strategy or project and program goals “to win a contract or satisfy a management or  client's/customer's unrealistic expectations.

IT Project and Program Plans and Schedules (Successful Lesson Learned)

Technology Project Management

IT project and program plans and schedules must be created and used for large scale projects and programs.

No one is saying that a plan is not subject to revision or change, but through control updating and change control processes. It is also a tool that supports status reporing including for "stand ups". But failing to appropriately plan is a serious mistake to make for large scales projects or programs.For large scale projects and programs (multimillion dollar contracts) more detail is required for planning, and that planning must extend further out to allow estimates to be more realistic and accurate. Customers/client must be comfortable with estimates for the money/cost for projects and programs. For Agile development processes this could be an issue with short term planning.

With the plans, at the Go or No Go gates, it will be important to examine where you are, if any modifications are required, or if it is a "No" to move on to the next phase or iteration required. Also, at the gates any adjustments that have to made, any refactoring that must be considered, can be evaluated. Revisions and changes to plans or the system/product's development can be approved through the proper Change and Configuration Control process.