What goes around comes around.

Recently I attended a networking group to network with a variety of IT and business professionals. It just happened that a project manager and quality assurance specialist stopped me to chat. The project manager made a comment that he had read my book several years back and that it was useful not only for understanding configuration management but it was useful for a recent interview he had in pursuit of a contract to manage an eReader development project.

As I had another engagement to make and was accompanied by a colleague, I asked why? He said it was about understanding the chip development process as your book states for firmware configuration management/development. I smiled and just made the quick statement: What goes around comes around. Thanks and glad the book has been useful through the years and into the 21^st century”. I have to be going but lets talk and share more the next time we meet, and by the way take a look at itprofessionalfacilitator.com.

The colleague with me stated, “Not bad”, what do you think?” I said that’s what it is all about, sharing the knowledge and lessons learned, and best practices. But my thoughts were also on another item. I had a call from  a recruiter representing a company in New York about eReader/eBook, web development opportunity.. It was only at the Project Management level and not at the program management level with the responsibility for the program, managing project managers and may include the PMO. Although my pursuit has been program manager or director level responsibility to include ensuring the success of system/application or web development projects, I understood when that project manager said that it (the book) had been useful to understand not only Configuration Management (CM) but firmware (embedded systems/applications) development as part of the eReader development/product project.

The IT Industry has Accepted Failure as the Norm

I recently wrote an article, significant to the IT industry, that was published in TechRepublic.

Click here for more information.

Program and Project Management Planning and Execution

Technology Project and Program Management

When considering planning for Program/Project Management, the Development Process/Methodologies, Configuration Management (including Requirements and Release Management), and Quality Assurance (Verification & Validation/Test),Best Practice Processes (BPPs), you must establish effective best (and good) practices.

The use of Best (and) Good practices ensures that H.O.P.E. (High Octane (Performing) Program/Project Execution would be the result of effective and realistic Initiation and Planning to increase the likely hood of success.

Conducting Large Scale Assessments and Gap Analysis

Technology Project Management

When you do an assessment and gap analysis you must consider:

1.      Business Processes (systems, policies, contracts, business rules, procedures, SOPs, etc.),

2.      Organization (Change, Culture, etc.)

3.      People (Skills, Training, etc.), and

4.      Technology (systems, applications, data/databases, interfaces, etc.)

5.      And must assess the supporting methodologies (program and program, and system development) infrastructure (desktop, servers, communications network, etc.)

Consider that on average, large scale, assessment will average 4-6 months.

The SDLC and How Program and Project Management Applies

Technology Project Management

My latest question that I answered in,

http://www.techrepublic.com/forum/questions/101-215110?tag=mantle_skin;content

Sorry, I only joined as an expert with techrepublic only recently but I would have wanted to answer and respond to the below question. I say never too late but it may be. I was concerned because I did not see an answer to this most important question. Just in case someone else has the below question, I will provide my answer to the question.

Project Management

“Hey there, im studying SDLC’s, can someone please give me there definitions of Project management, and how it is implemented in the system development life cycle (not software development lifecycle)”

My comments:

Yes, good study area. When you refer to the SDLC, originally known as the system development life cycle, it is also currently known as the System/Software Development Life Cycle (SDLC). Often the software development portion of it is used for software and application development of a single product, software system or application. See if your study verifies this.

If I am correct, you want the perspective of the system development life cycle as a whole and how project management fits within this context. This link here provides a diagram of the SDLC and reflects the integration of how /where project and program management applies. This diagram also reflects how configuration management and quality assurance’s verification and validation are integrated within the SDLC. LinkLDamon this link has to be put in after you change the URL or leave as I change it or suggest another one to show “system”.

Program and Project Management does apply to the system (and software) development life cycle. See links below for a definition and explanation of project management. There is a definition/explanation for Program Management as well. Both of these management disciplines apply to the SDLC. It is Program management that applies to the system as a whole and it is project managers (project management) that manage each subsystem/component of the system. It is an allocation or breakdown of the system into subsystems, components, and other major components that become projects to be developed and integrated, or delivered to be integrated, into the system. You also may have subcontractors or vendors developing development and/or delivering components of the system that may be projects. These deliverables are integrated into the system as well during system integration before system testing and qualification.

Additional Resources:

1. Responsibilities of a Project and Program Manager
2. Project and Program Management Differences

But remember, within the System Development Life Cycle lies the software and hardware (subsystems or components of the system) development life cycles. The software could be software and/or firmware (embedded program systems).I hope that is helpful and useful for your studying.

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)

 

IT Project and Program Teams (and Individual Members) Require Acknowledgement and Recognition...

Technology Project Management

 

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.

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.

 

Why I was Successful as a IT Program and Project Manager

Technology Project Management

 

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).

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

 

Project/Program Management: Knowledge must be transferred in the IT industry

  Technology Project Management

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.

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.

Technology Project Program Management

Technology Project Management Best Practices

Project Managers, Business and System Analysts have Different Responsibilities

Recently their have been job descriptions requesting a Project Manager/Business Analyst (PM/BA). A Business Analyst and Systems Analyst (SA) have different roles and responsibilities. A BA relates to the Business side and gathers requirements and specifies/documents business requirements and SA relates to the Technical side and analyses is problems, supports the determination of solutions and business requirements to create and specify functional and non-functional requirements.

That's why is it important to understand the differences and that anyone applying for a BA or SA position must pay particular attention to the responsibilities and skills sets/qualifications required. The PM, BA, and SA have different roles and extensive responsibilities. With a small project you may have a PM doing some BA work but don’t kid yourself. For intermediate and large scale projects and programs they have full time responsibilities. Many IT Project Managers manage multiple projects but the responsibilities are basically the same.

The Need For Proven Best Practices For Project Success

Technology Best Practice Processes
 
There are serious concerns going forward in 2011 regarding IT project and program failures, including ERP, SCM and VOIP. Some IT professionals in the industry don’t think that changes required to reduce the rate of failure, or to stop this disastrous trend, is forth coming. In one article this seems to be the case, including a statement by an IT professional, “…he sees no immediate end to trouble projects….”
 
But with knowledge transfer, the documenting and USE of lessons learned and best and good practices there would be changes that increase the success rate for IT projects and programs. Also Best Practices are subject to improvement, must be used before the project or program is initiated (feasibility, to determine what is the best solution), be used for implementation or execution, and for closing out projects and programs.
 
Serious steps must be taken by IT professionals, senior management, Vendors and Subcontractors, e.g., system integration and developers, and customers.

Yes, there are several significant challenges and issues (See 10 ....) that lead to troubled or failed projects or programs)and but there are solutions and we must be diligent and committed to make the changes to increase the Success rate.
 
And while we have listed Challenges and Issues that lead to troubled and failed projects and programs, there are several more issues:
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.
 
[Read More...] Proven Best Practices are being presented to overcome the Challenges and Issues.

Total Quality Management

Technology Project Management Best Practices

Whatever happened to Total Quality Management (TQM) which was a focus on a company’s internal requirements to improve the quality of its operations, products and services, with a customer focus? The emphasis was that quality is the responsibility of everyone, and it provided a feedback process and mechanism for employees and staff to submit suggestions for improvement. Is it just a buzz word during theses difficult economic times?