http://www.devx.com/enterprise/Article/46472

Internet.com

Comments to:

9 IT Project Management Mistakes That Will Sink Your Project

Your article identifies some good points to ensure your project stays on track.

As I read the article and reviewed some of the comments I had several comments.

Eddie Williams Comments:

PM Pitfall #1. Inaccurate Scheduling

Planning and estimates must be realistic and accurate. But it is having the right/appropriate people participating and providing input that will achieve that goal.

PM Pitfall #4. Being Too Passive

Good leadership along with the required management skills is required by a project manager. Two reasons or factors that lead to project failure are poor or inadequate leadership and communication. Leaders influence and motivate others, set an example, direct and guide a team(s). Project managers must have good management and people skills. They must not just manage the activities and deliverables of the project life cycle. They must also manage teams; people. It is teams that ultimately accomplish the objectives of a project. Teams comprised of members getting the job done, involved and committed to the goals and objectives of the project/program and business.

To be in business just to make money is a narrow view of why you’re in business. Would that be the primary reason and focus? What does that say about your business purpose and mission? Are they directed toward the customer, the products and services you are providing to the market? The money (and profit) will come when you service the customer well. The statement should be…Do what the role calls for and take charge and manage the project and people through project close out.

I conclude the above comments with the following:

I recall several years back being a member of a business and professional network group. Several individuals made a strong statement, “I’m in it to make money”. I, not wanting to really debate at that time (but I did ask some questions, kept what they said in mind. Several years later I had two of these business owners and professionals approach and engaged me in conversation. They had recalled the questions I had asked. One of them stated, “Several years back I forgot what I was in business for and who my market and customers, consumers, and users were. I lost focus and my business and my people (employees) paid the price.”

Why learn a lesson the hard way. Know and understand why you are really in business. State it in you purpose and mission statements. Realize your vision. Achieve your goals, accomplish your objectives, meet or exceed your expectations and align your projects and program with your business plans and strategies – the money (and profits) will come.

PM Pitfall # 7. Allowing Scope Creep.

I won’t say much here accept set up and establish a change management process (with a configuration control process within) in the beginning of the project and ensure it is conducted throughout the project. It will address potential project changes, problems or discrepancies, and product/system configuration changes. Also include a process to expedite critical or time sensitive changes that require review and approval. Within that process you are controlling scope creep (considering scope of work and scope of requirements).

PM Pitfall # 8. Having No Pilot Phase.

I like here considering the importance of a pilot. I believe and encourage use of pilots, Proof of Concepts, prototypes and mock-ups and review and testing. Used and created/developed as required with the customers and users involvement and participation early and throughout the project.

General comments:

Build a core team that will have the appropriate skills sets, be involved committed and whose team members are empowered to do their jobs, meets the goals and achieve the objectives, and most importantly bring the project to a successful conclusion. Also acknowledge and recognize the team and members accomplishments and achievements.

There are no silver bullet methodologies, neither past nor present. But we have come a long way by improving development processes and methodologies. But each methodology has gaps depending on its application and can be improved (keep that in mind) and sometimes those gaps in using one or another methodology may mean that you may have to use activities of another to fill gaps. My experience has been just that, with successes throughout my career. Ensure that you are involved and that the customer (and users) is involved, participating and is commitment from the beginning and throughout the project.

Much of what you plan and execute/implement should not be unknown to the customer, users and others. If so, it is high risk. You want to consider not just time, but approved budget(s), performance and quality, and customer and user satisfaction. That has been the case for me and the teams built. After the lessons learned in the beginning of my career that has always been my take. It surely supports knowledge transfer.

Note: It is not micro management to ensure members are completing assignments; getting a daily status.

In my reading and research… this article’s title surely got my attention:

Stop with the Lessons Learned

=> Click Here To Read The Full Article

Correct me if I am wrong but it seems to me that the article is indicating that a lessons learned (post mortem) be conducted “a week before the end of the project…”, and I thought it was positive “…linking lessons learned with project initiation, promoting knowledge management and presenting the lessons learned to the project sponsors was a key takeaway.”

But my concern is a project, small or large, has a lot of processes and activities, especially for a full SDLC development project or program. We know the failure rate of projects is high, so we must learn from documented and used lessons learned. It would seem that waiting until the end defeats the purpose to learn within the current project or program. That learning could change the course of a troubled or failing project or program. Lessons learned can be extensive at the end of a project. In one of my early projects the team members could not recall all the significant lessons learned. Who has that kind of memory to recall? Someone in the meeting said they had forgotten some of the lessons learned. From that point on, teams I have managed had opportunities to document lessons learned before the end of the project. I have not had just one lesson learned session for a project or program, and surely not just one at the end; post mortem. Lessons learned must be documented, and lessons learned sessions must be conducted, throughout the project or program.

A best (and good) practice: (an early career lesson learned)

Document lessons learned after each phase, processes/activities, and major tasks and not just at the end of the project (post mortem). Yes, document lessons learned during each phase/process/activity of a system or software development life cycle (SDLC) (requirements definition/analysis, design, implementation/construction, test, delivery/deployment, and support/maintenance) and after each activity, task, and deliverable. (Note: In one company they had you document lessons learned for the entire engagement process; from discovery (including Sales and Contract activities) to project close out.)

Share and archive also for future projects and programs use. Establish a repository or database to store project and program information, knowledge base and lessons learned. Create a feedback mechanism for lessons learned to be submitted for gathering, organization and periodic review. This also allows empowered team members to submit lessons learned on a continuous and periodic basis. Ensure/enforce the use of lessons learned through PMO, if you have one. And, yes, lessons learned should/must be reviewed before a project’s or program’s initiation, especially for any similar or related projects and programs being initiated.
Ensure customers’ and users’ participation in the beginning, and throughout a project, which would allow them to be part of the knowledge transfer and lessons learned processes and activities.

See related articles about documenting and using lessons learned:

• Documenting Lessons Learned
• Tips on Lessons Learned

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, are forth coming. In one article this seems to be the case, including a statement by an IT professional, “…he sees no immediate end to troubled 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.

Listen to the most recent ERP Failure Podcast:

Download this ERP Failure and Proven Successful Best Practices White Papers Here.

Project/Program Management Lessons Learned

“It’s about Management Control and Quality”
Turn the listed items into checklists to be used for assessments and evaluations.

The following is a list of lessons learned that have been identified and documented during a successful career of executing projects and programs.
1. A project manager must not only be responsible, but be accountable, for the project.
2. Programs/Projects must be aligned with the overall business plan and strategy.
3. Understand the proposal, contract and standards referenced for use on a project/program.
4. Obtain senior management support and commitment.
5. Conduct business with high ethics.
6. Use Best/Good Practices, tailored to the project and program.
7. Prepare a complete activity, work or task breakdown (known in the industry as a WBS), reviewed by key team members and accepted by the customer.
8. Document lessons learned during each phase/process of a system or software development life cycle (SDLC)(requirements definition/analysis, design, implementation/construction, test, delivery/deployment, and support/maintenance) and after each activity, task, and deliverable.
9. Have customers and users participation in the beginning, and throughout, the project.
10. Don’t overlook team building – having the right people with the right skill sets.Having a stable “Core” team is essential.
11. Build teams while considering retention and backup plan and strategies.
12. During the sales and proposal stage ensure key people are involved and participate in reviews (e.g., PMs, System Architect, Lead developer, or other leads).
13. Ensure all team members (including client/users) understand the project plan (get buy-in from leads/inputs to the project plan).
14. Document other agreements or expectations in the “Future Consideration” of the requirements document (Including for Agile or other iterative development processes. The limited or specific documentation used for Agile and other iterative development processes should be contained in a document.).
15. Provide realistic estimates of project activities and costs.
16. Perform Configuration Management (CM) and Quality Assurance (QA) to ensure good product development management, compliance and that quality is built into the product, as both (CM and QA) begin at the beginning of the project. Don’t confuse configuration management with just documentation and don’t confuse quality assurance with just testing. (link (or see) book or articles)
17. Determine which development process to implement for the project: Agile, Iterative, waterfall, or combined elements. Traditional or Iterative and incremental development may be required depending on the solution and complexity of the project. (Each or combined elements have been used in past project successes)
18. Product requirements must be defined, understood and documented (specified) up front and/or throughout development for iterative development processes (Agile, etc.) (Must be traceable back to business requirements and throughout development, mutually agreed to and signed off).
19. For Agile development, ensure that an architecture is created, documented and developed to understand, agree to, identify and determine the up coming iterations.
20. A company’s culture and politics cannot be ignored.
21. Prepare a traceability matrix to accompany requirements documentation. This document can also be used as a check list.
22. Identify, document, and manage risks before execution of, and during, a project.
23. Develop a communication plan and execute it.
24. Document terminology and definitions. Include in planning and requirements document/documentation.
25. Ensure that audits and reviews are performed/conducted for oversight and to ensure consistency and compliance.
26. Perform and document usability testing when required.
27. Establish a centralized repository – containing a knowledge base, lessons learned, project information, templates, etc.(Could be web based or intranet)
28. Ensure knowledge transfer and training takes place.
29. Document and share lessons learned, but more important use them.
30. Ensure a mechanism for feedback for improvement is in place.
31. Monitor and obtain customer satisfaction/dissatisfaction throughout the project (inquire/survey).
32. Close Out Project. Ensure that (not limited to or in a particular order):
a. A project close out meeting is conducted with the customer/client to define that all close out criteria have been satisfied (financial included)
b. Any issues are addressed
c. Lessons Learned are shared
d. All deliverables (product included) were signed off and delivered
e. A repository is set up (or was) and all documentation/data archived
f. All team members are formally released from the project
g. The project success criteria was met and is reviewed
h. The project performance and evaluation reports were completed (performance reports provided to team members line managers if project supported a matrix environment)
i. A team close out meeting is conducted to the thank the team (recognized and/or rewarded)
j. A final survey/evaluation sheet or form for customer/client input is left with the client (to be provided back to the company)
k. A letter for close out is signed by customer and project manager

1. Prepare and develop a quality management and assurance plan (incorporated) for QA- (which includes verification & validation, test methods/testing, and quality control) in compliance with standards and tailored to the project or program
2. Conduct an assessment, as required
3. Select and use QA automated test tools – Rational, Mercury, Silk, etc.
4. Review and audit plans, processes, and activities. Develop a plan to perform the required activities, share with the affected functional areas or groups. Tailor to the project or program.
5. Track errors, defects, and identify trends
6. Review business plan, strategy, financial/budget, and the contract requirements, standards, and regulations
7. Develop and use procedures and checklists to perform and conduct QA
8. Document all QA activities/processes for each phase, as required
9. Create test strategy based on solution/approach/methodology
10. Create test strategies and plans based on requirements and design
11. Participate, perform or witness and certify functional and system tests
12. Participate on change and configuration control review and corrective action review team/board
* Identify and select the appropriate tools, applications, and methodologies

Worst/Bad Practices
1. Just using QA for only testing and not Verification and Validation/Testing because QA ensures compliance and building in quality (Must allow for the review of the solution and any contract requirements, project and product requirements, the development methodology and processes in the beginning of the project or program to set up the QA verification and validation process. If Quality Assurance is not involved early, this can not take place.)
2. Not introducing QA early in a project and program

1. Identify the appropriate approach and solution based on the problem(s) analysis and business requirements
2. Conduct as, and when required, the appropriate assessments for the business processes, system, applications, infrastructure, and/or network early and in a timely manner.
3. Determine if Rapid Application Development is required
a. RAD/JAD
b. Prototype and mockups
c. Facilitated sessions and surveys
4. Select a model and implementation methodology (RUP, others, PMI, Agile, Iterative and Incremental, Waterfall, etc.)*that is appropriate for the solution
5. Use Development and Configuration Management/Control Tools *
6. Document terminologies and abbreviations and include in proposal/contract and development and implementation documentation (especially in requirements and design documents)
7. Select IDE (including CASE) if required and conventions to be followed* (example: esclipse, etc. ). Typically an IDE is dedicated to a specific programming language as to provide a feature set which most closely matches the programming paradigms of the language. However, some multiple-language IDEs are in use, such as Eclipse, ActiveState Komodo, recent versions of NetBeans, Microsoft Visual Studio, WinDev, and Xcode.
8. Select and conduct technical reviews (schedule them)
9. Perform development and system testing, use as required automated test tools *
*Identify and select the appropriate tools, applications, and methodologies

Worst/Bad Practices
1. Not including users/customers in the beginning of a project and throughout the development process. Not trusting their participation, commitment, and collaboration as a team member. (They are the ultimate users and benefactors.

1. Plan realistic scope and Task/ WBS (Work Breakdown Structure). Ensure it is a Collaborative activity between business and technology.
2. Estimate realistic schedules, resources required and cost (determine min, mid, and max)
3. Ensure Development has conducted any necessary assessments of the organization, system, applications, infrastructure, network, etc. Conduct a project management assessment if you are coming onto the project or program after it has started.
4. Document and archive lessons learned after each phase/process/activity/task and not just at end of the project, and use in the present and future.
5. Utilize the experience and knowledge of the Business Client, Customer, and Users. Take advantage of this relationship. It’s a partnership!
6. Commit to and maintain subcontractor/vendor control
7. Participate in resource selection and Management/Team Building. Ensure that a backup and retention plan is in place.
8. Build teams with the right skill sets (hard(technical) and soft (communication, etc.)
9. Plan and implement the required education/training for clients/customer, users and staff.
10. Conduct a Kickoff meeting – introductions project vision, goals, objectives, buy-in , etc.
11. Establish a project repository/Database (Knowledge base/lessons learned/project data)
12. Use PM tool(s) * -MS Project, PMI methodology, Primavera, etc.
13. Establish a Change Management process which includes a Configuration Control process when the project is initiated (in the beginning). Establish a process within the change management process to expedite critical changes.
14. Identify and manage risks. Have a system perspective for development and implementation. Determine the impact on technology, organization, people, processes, and other systems.
15. Prepare and execute a Communication Plan that addresses all levels (senior management on down to functional and department management, and the team(s). A plan will include the required information for each level of communication, performance, and status reporting, frequency, and content required.
16. Establish a feedback and improvement mechanism/process for program, project, and processes.
17. Conduct management reviews (plan and execute) – create and develop a process, procedures and checklists.
18. Monitor and survey customer and users satisfaction on a continuous basis for each and every project and program
19. Report on status and earned value
20. Report on performance (metrics)
21. Close out projects (Contractually and Administratively)(See lessons learned)
*Identify and select the appropriate tools, applications, and methodologies

Worst/Bad Practices (As required)
1. Project Manager/team, not planning realistically for scope, schedule, and cost without feedback and buy in. Consider all as part of SOW/Proposal, with experience leads’ input and buy-in. Don’t just use a % of, without realistic input from the appropriate department, managers, and leads. Get support and commitment from Sr. Management.

1. Perform Configuration Management up front and throughout projects and programs (See book and articles to understand and apply Configuration Management
2. Conduct an assessment, if required
3. Select tools, methodologies *
4. Perform Requirement, Design, and Product Management
5. Prepare a requirements document/documentation or specification with a traceability matrix. For the Agile development process the documentation may be …)The functional and physical/design characteristics are defined: Configuration Identification)
6. Identify and label documents and products
7. Establish library/software control * (we have versions control software)
8. Baseline (or document and approve for control purposes) requirements, design, code/product/system – a basis for control (including financial)
9. Establish a Configuration Control process and entity (review team/board/committee). As part of the overall change management process.
10. Document a release management process (sprints in Agile for iterations and increments)
11. Address and implement security and access control
12. Create and keep Status Accounting reports
13. Conduct functional and physical examinations
*Identify and select the appropriate tools, applications, and methodologies
Worst/Bad Practices
1. Considering and implementing CM as software identification/labeling and version control without requirements and design management
2. Implementing CM as documentation (data administration) and not product definition and control for the system or software development life cycle (SDLC)
3. Not implementing CM and Configuration Control in the beginning of a project and program, under Change Management