Configuration Management Defined

Technology Best Practices

Research over the years to understand what is “out there” for definitions for Configuration Management, especially system and software, leads to many difference and inconsistencies. Two in particular are:

1. http://searchcio-market.techtarget.com/sDefinitions
2. http://en.wikipedia.org/wiki/Configuration Management.

The former is incorrect or not complete enough which could lead to confusion, misunderstanding and incorrect, or incomplete, application of configuration management to any project or program. Refer to ITPro articele (=> Configuration Management Explained)  for an understanding of applying configuration management.

Project and Program Manager Responsibilities #pm

Technology Best Practices

Managing projects and programs. A Project and Program Manager must be responsible and accountable. Whether you like it or not you are the leader, and not just a facilitator. It’s is also easy to be a “yes man” (person) but harder than you think to say “no” to a your boss/management, stakeholder, customer/user. But when it is necessary if you see a troubled project or program, speak up, document the issues with justification. Present your case well.

The buck stops here/at the top: Leaders/Leadership – takes responsibility, be accountable – (Read: Management and Ethics) Understand there are consequences whether good or bad. There are consequences/unknowns but do the right thing, be ethical, have some integrity. Yes, be trusted.

Project and Program Management Office (PMOs)

Technical Best Practice Processes

P/PMO and program management, buzz words at one time and often the value not
understood by many the past 5-10 years back or the latter part of the 20th century,
especially in the commercial environment, but now an emphasis for past several years
to drive IT and technology implementations.

But failed IT projects have required stronger management and control: Now, over
the past 5 years, especially in the commercial environment, establishing program and
project management offices necessary and why?

Some benefits and advantages:

• Governance, with standards Project and Program Management methodologies
• Cost Saving with consistent and standard project and program management
• Profitability Improvement
• Productive and successful projects and programs
• Organizational and business operational improvement
• Cultural shift to project and program management
• Staff professional development in project and program management
• Standard tools and techniques
• The maturity of Project Management (PM) – improvement (change, lessons learned, knowledge bases-knowledge transfer), advancing to program management, and establishing effective Project/Program Management Offices
• Trained and coached project and program managers

 

Statistics over IT project/program failure rate.

Technology Best Practice Processes

Read full post here: http://www.it-cortex.com/Stat_Failure_Rate.htm

Researchers have been reporting on IT projects and programs, enterprise-wide, failures
but what about the successes and why? We have all heard, and are reading about the failures
of large scale projects such as Enterprise Resource Planning
(ERP failures + Success) and enterprise-wide system and application implementations. But how can
they be successful? We can help the failures by using proven best practices!

>> Read the ERP Failures and Proven Best Practices Whitepapers

ERP Failure 10 Implementation Flaws - ERP Success Best Practices Technology Project Program Management Best Practices-Lessons Learned

Technology Best Practices

ERP (Enterprise Resource Planning): Top 10 Reasons for Failure

=>Download Your ERP Best Practices Report & Comparison Guide

With many information technology projects considered failures (see Standish Chaos Press Release) during the last decade, where do we go from here?

When considering implementation of ERP (Enterprise Resource Planning), an organization must determine the best solution for their business operations. Overcoming the challenges presented is critical to have successful implementation of an ERP solution. It’s interesting that many failed ERP implementations have much in common with other large scale IT failures.

The following are challenges that have led to troubled, or failed, ERP projects and programs:

via Continue For More

Project Management Failures

Technology Best Practice Processes

I was recently reading a good article on “Five tips to learn from project failures”. While reading the tips I had some valuable comments.
Click here to read the referenced article...

http://www.zdnet.com/blog/projectfailures/five-tips-to-learn-from-failure/11187?tag=mantle_skin;content

Due to the project scope being fixed for the period of time, but the customer's business constantly changing, the customer usually wants to change their scope frequently. And what is even worse is that the larger the project, the more likely it will be that this will happen. So here are five tips to help you manage the scope of a project.

General Comments: Yes, a project’s scope is fixed (or is accepted and approved) until there is a change that is reviewed and approved. . If it was outside of the approved scope (current/baselined), then estimates are determined and the new and approved scope with a revised plan that is executed moving forward.
It’s not that customers usually want to change their scope but businesses will always be in a state of change (including their expectations). This is business life, within the life cycle of the business world. Requirements and expectations change based on internal and external forces.
1. Cast in concrete.
This may seem easy, but it is very important that the scope is defined properly and in very much detail.
Comment(s): The above statement is correct but realize one important fact, change is inevitable, so establish an early change and configuration control process with a review team. Also establish a process to expedite change that requires quick turn around. The above means that change management and configuration management is established early for any project and program.
That scope includes all required tasks/activities based on the statement of work, charter, and requirements for a project or program. The next item’s comments say where information is captured, documented, and controlled.

2. Proper Planning.
When doing the project plan, it is best to group all the activities in relevant groups that are associated with your deliverables. This way you can easily and quickly see which activities contribute to the delivery of which deliverable.
This will also ensure that once you have completed a group of activities, that you can mark the deliverable as completed. This will also add the benefit of easily reporting on the status of each deliverable and to monitor the progress on each deliverable.

Comment(s): That is why when you have determined what the solution is and selected a development methodology to be implemented, a plan is created with milestones and deliverables. The project or program plan is called a breakdown of tasks or better known as the Work Breakdown Structure (WBS). It’s broken down into identified groups, phases/stages/processes and activities and tasks. Broken down to a task level where resources, with rates, can be assigned to assist with estimating.

3. Quality measurement.
As important as it is to complete and deliver a deliverable, is it to ensure that you deliver the quality that meets the need of your customer. These expectations that describe how the deliverable will be measured to ensure they meet the customer's expectations are called 'quality targets'.
To ensure that you meet these quality targets, will require that you have 'quality controls' in place. These controls will ensure that the deliverable will do what it was set out to do. Only when this is in place, will you be able to ensure that your customer will sign off each deliverable and the project as a whole.

Comment(s): That is why configuration management and quality assurance/quality control are established early in a project and program. Configuration Management (CM) established early before, or when, requirements are specified to ensure all requirements are specified and documented and to identify all product/system/application deliverables. Establish the quality assurance/control processes to ensure compliance, that quality is built in, and that all approved requirements are met. When this takes place QA will certify products/deliverables so that customers can review and sign off on deliverables and the project or program.

4. Managing scope change.
Every time a customer requests a change to the scope of the project, ensure that the requirements are properly documented and review the impact on the project deliverables. Ensure that once you have documented any impact, being cost, time or deliverable change, the customer signs the scope change document. Then make sure that the additional resources, time, money or people are provided and assigned to the project. Where necessary, hold scope change meetings to discuss the change and prioritize against the current deliverables.

Comment(s): Good, and that is why change management and configuration management including configuration control is established early and as a formal process. (See items 1 and 3’s comments)

5. Reporting.
All changes and their effect on the project must be reported appropriately. This will ensure that if you go past the project deadline that you can prove that is was due to a scope change. This way the stakeholders will be more acceptable to the slippage.

Comment(s): Reported, documented, reviewed and evaluated.

Thus by defining the scope properly at the start of the project, adding your deliverables to your project plan, manage any scope changes and monitor the quality of all deliverables you will be able to manage the scope of the project in a more formal manner, which will give you the benefit of a better managed project.