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;contentAlthough 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:
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
The project or program scope, its approved budget(s), the project plan and schedules, resources (manpower, money, equipment, etc), procurement and subcontractors/vendors
The System/System Development Life Cycle (SDLC) i.e., requirements identification and analysis, Architecture/Detail Design, Development, System Test, Delivery/Deployment)
IT Project and Program Teams (and individual members) require Acknowledgement and Recognition ...
because without them their would be no success!It’s about Team Success! I enjoyed and I am enjoying my career as a member of those teams.I was proud to be a member of the teams: IT project and program teams built by the project or program manager and team Leads (Business and Technical). I appreciated the teams very much. And with their success came the acknowledgement and recognition they deserved as a team and as individual members. Management, Project and Program Managers and team Leads must never forget this fact: That unless you are a "one man "show" success does not come without team success. That success, the team’s success, my success, I attribute to committed team members (empowered team members), with knowledge transferred by their interactions, and through their use of lessons learned and Best Practice Processes' (BPPs’) best practices. The teams, with the appropriate methodologies, were proactive to address potential problems, issues and risks with open communication throughout the projects and programs. And even with their individual goals they were teams that were committed to the primary Goals and Objectives of the projects and programs.
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.
Why I was Successful as a IT Program and Project Manager "What has contributed to your success?"(A question I get at conference presentations and within coaching sessions) I began my career in the Aerospace and Department of Defense (DOD) environments. And before I became a project and program manager in those environments and the commercial IT industry, I had held positions as a specialist in Development (Systems and Procedures Analyst, etc.), Configuration Management and Quality Assurance. I attended training sessions to understand standards and regulations for these disciplines or processes along with creating plans that had to be approved, applied and used for system engineering and IT (as we now know it) development projects and programs.
Best Practice Processes' best practices, Knowledge Transfer, and Lessons Learned Except from an article and my response: “…Several years back and during my early project management career I was working for this IT company. I was told that there were concerns for each time I had to take on a new project in a different technology or business environment: system, software, application, migration, infrastructure/networks, web development, e-business and e-commerce. But because of my past success, senior management had confidence in me. I recall also being taken aside by a trusted manager and being told that several managers were concerned about me being as successful in network development and migration projects as I had been in the software/application and system engineering development environments? (Note: large scale system, database, and system integration development projects and programs…and don’t think I didn't consult with the technology experts, receive on the job training and attended classes about a variety of technologies and their resulting benefits.) I just laughed and said to him that we will just have to see. I was not concerned if I did what I do best and lead with what I have learned (lessons learned), and built the “right” team and planned and effectively executed the what called Best Practice Processes (Project/Program Management, the Development Process/Methodologies (which addresses the SDLC),System/Software Management and System/Software Quality Assurance).
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.
Project/Program Management: Knowledge must be transferred in the IT Industry Seasoned IT professionals no longer in the work force to provide knowledge transfer (laid off or retired), Inexperienced and experienced IT professionals working extended hours, having extensive and dual responsibilities, burning out. You also have confusion about Business Analyst (BA) and System Analyst (SA) roles and responsibilities. Their skills set are different with one having more business process and requirements knowledge and more technical (product/system) modeling and functional requirements knowledge. The skill sets and roles are different. In some cases now the roles and responsibilities are being required for one position, but ensure that the skill set exist also. This is why knowledge transfer, the documenting and use of lessons and learned and best (and good) practices is absolutely essential to reverse the trend of an unsatisfactorily projects and program failure rate.
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.
