Thursday, December 1, 2016

Agile coaching at a very large product company


 

Tuesday, November 15, 2016

Applied project management #16. The control chart

The Control chart and the rule of seven

One of the contractual clauses of a project is strict adherence to a schedule variance within +- 10 percentage. The customer will do the review of the project every fortnight, and if the schedule variance is above 10% then there is a penalty clause. That is the customer specification limit. Will you go for that project or not?, that is the question.

If the supplier's capability limits (UCL - Upper control limit, LCL - Lower control limit) is within the customer's specification limit, then there is no risk involved. If the suppliers capability is below the customer specification limit, then there is a risk. We may still go ahead with the project, by taking appropriate risk response planning, and contingency planning.

Once the project starts, the fortnightly reviews start and we get data points a,b,c,d,e,f,g,h,i,j,k. Data points a and b are within the customer specification limits and within the organisations capability limits (LCL, UCL). So the customer and the quality control department will not complain. The data point 'C' is outside the organisations capability limit, so the QA department will complain. Since it still within the customer specification limit, the customer will not complain. In this case we have to perform a root cause analysis (RCA) to understand the root causes leading to this deviation, in order to correct it.

The data point 'D' is surely an outlier. It is lying beyond the customer specification limit. The customer will complain. Again we have to perform a root cause analysis to understand the real root causes and correct them. The root causes can be random or assignable. For random causes we will not be able to take corrective / preventive actions, where as for assignable causes we can.

After the corrective action, the subsequent data points e,f,g,h,i,j,k are within the customer specification limits, hence there wont be any customer complaints. Of these f,g,h,i,j,k are happening next to each other. Whenever we see a cluster of seven data points happening next to each other we call it as 'Rule of seven'. A rule of seven can happen anywhere on the control chart. Whenever we observe a rule of seven, we must perform a root cause analysis to find out why it is happening. If the rule of seven is happening within the UCL and the LCL, then we can infer that something good (best practices) are happening, and we must investigate so that we can institutionalise them. If the rule of seven is happening outside the LCL and UCL, then it could be because of some bad practices. In this case, we must correct and prevent them from future occurrence.

All the quality gurus like Deming, Juan, Crosby were dead against slogans of improvement. They always believed in measurements. Without a control chart , no reliable and sustainable improvement is possible. 

Wednesday, November 2, 2016

Applied project management #15. Enterprise environmental factors and organisational process assets

Enterprise environmental factors and Organisational process assets

Enterprise environmental factors

Before embarking on a project, the project manager and the team must have an in depth understanding of the enterprise environmental factors, failing which the project risk can be very high, leading to even cancellation of the project and huge losses to the key stakeholders. The following is a sample list of enterprise environmental factors that may have a major impact;

Availability of resources (man, machine, material) to execute the project
Pollution norms laid out by the government and the environment protection groups
Waste disposal norms
Legal system
Political climate
Climatic conditions
Labour laws of the country
Culture of the land
Festivals of the land
National holidays of the countries which has an impact on the key stakeholders of the project
Local business ethics

Watch this video about enterprise environmental factors;
https://youtu.be/PDwKcDe4IPw



Organisational process assets

Any reusable component from any of the key stakeholders, that must / can be used for the project falls under the organisational process assets. This include, but not limited to;

Proprietary intellectual property of the customer, supplier
Templates
Procedures
Guidelines
Historical data
Project management information system

Both enterprise environmental factors and organisational process assets have major impact on the planning and execution of projects.

Watch this video about Organizational process assets
https://youtu.be/kPYdbhXSzOk





Wednesday, October 26, 2016

Applied project management #14 Developing the project management plan

Through the project charter, the project manager for the project is identified. Now, the designated project manager leads the project into the planning phase, which comprises of developing the integrated project plan. Project teams comprises of multiple sub teams like;

Engineering team
Planning team
Procurement teams
Quality assurance team
Risk management team
Human resource management team
Communication team
Documentation team etc

Unless and until these sub-teams complete their individual plans, the project manager cannot complete the integrated project plan.

The project management plan is the document that describes how the project will be executed, monitored, and controlled. It integrates and consolidates all of the subsidiary plans and baselines from the planning processes.

The project baselines
Scope baseline
Schedule baseline
Cost baseline

The subsidiary plans include;
Scope management plan
Requirements management plan
Schedule management plan
Cost management plan
Quality management plan
Process improvement plan
Human resource management plan
Communications management plan
Risk management plan
Procurement management plan
Stakeholder management plan

The project management plan may include;
Life cycle selected for the project
Details of the tailoring decisions
Description of how work will be exceuted to accomplish the project objectives
Change management plan
Configuration management plan
Key management reviews for content
Requirements and techniques for communication among stakeholders

Tuesday, October 25, 2016

Applied project management #13. Project chartering

Companies have very limited resources, and they must deploy them on the best projects which will yield maximum benefits. Project chartering is the process of officially approving the start of a project by the senior management / sponsor. The project charter is prepared during the initiation phase of the project, and the accountability for preparing the charter is with the project sponsor (senior management representative). Once approved, all changes to the charter must be re-approved by the sponsor.

While developing the project charter one can refer to;
  • Statement of work (SOW)
    • Business need 
    • Product scope description
    • Strategic plan 
  • Business case of the project 
    • Market demand 
    • Organizational need 
    • Customer request 
    • Technological advance 
    • Legal requirements 
    • Ecological impacts 
    • Social need 
  • Agreements 
    • Contracts 
    • Memorandum of understanding (MOU)
    • Service level agreements (SLAs)
    • Letters of intent (LOI)
    • Verbal agreements 
    • Email or other written agreements 
  • Enterprise environmental factors 
    • Government standards 
    • Industry standards 
    • Regulations 
    • Organizational structure
    • Organizational culture 
    • Market conditions 
  • Organizational process assets 
    • Organizational standard processes 
    • Policies 
    • Process definitions 
    • Templates 
    • Historical information 
    • Lessons learned knowledge base 
    • Project management information system 
The output of the project chartering process is the project charter, a light weight document (3-5 pages) and contains but are not limited to;
  • The high level scope of the project
  • The business case of the project
  • Alternatives analysis
  • Assumptions
  • Constraints
  • High level risks
  • Major milestones with dates
  • Key stakeholder details
  • Project manager's name, roles and responsibilities
  • Project approval requirements 
An approved charter  is the green signal for the project to proceed, and is a great reference document for the project manager, team to understand the project quickly. Since charter is the only document where the project manager's name, roles and responsibilities are defined and approved by the senior management, we say that the project charter gives authority to the project manager. Many projects have multiple managers / stakeholders, and a well defined charter brings in lot of role clarity, and avoids organizational politics.




The 'project chartering' process and the output of the 'project chartering', the  'project charter'   ensures the right foundation for the projects and gives better continuity to the projects.

Think of situations where the project manager changes during the course of the project, or change in sponsor. Having a pre-defined and approved project charter gives the project with a strong foundation and provides it with better continuity, despite changes in the environment.

PMBOK Version5 reference page numbers 66,67,68,69,70,71,72


Monday, October 24, 2016

Success motivates

Hi Sirs,

After a long gap between the coaching and exam, i had scheduled my PMP exam for today.

Happy to convey that I cleared the exam. 

Thanks for your training and support

Mock exam really helped to identify the gaps and focus areas.

-- 

Best Regards,
Vivek