Happy to see that one of the key chapters of my Dutch book Scaling agile in organisaties is now not only available in English but in Portuguese too. O GERENTE DE PROJETO SOBREVIVERÁ NO MUNDO ÁGIL?
Being a Project Manager – A different Book on Project Management by Hamutal Weisz and Daniel Zitter focuses on the essentials and practice of project management.
I love the process of baking bread as a metaphor for project management and all those related colorful pictures throughout the book.
Project management is the ‘flour’, the base; its function is to create the path to the goal. Project control is the ‘yeast’; its function is to influence all the other ingredients and ensure that the project progresses according to plan as it moves towards its goals. Communication in the project is the ‘water’; its role is to unite the efforts of all those who are working on the project.
The back cover explains that this book is suitable for managing any project of any size, subject and control. And here, I have my doubts. Looking back at the metaphor, I think this only works for more traditional projects or waterfall projects. If I want to use a more agile approach, the metaphor and the book will be of no help. This book is very prescriptive and explains a very bureaucratic way of working.
But after narrowing the scope (only traditional waterfall projects) there is still a lot of value in the book. In line with the metaphor the book is divided into three sections project planning, project control and project communication. Every chapter ends with a conclusion and a summary of corresponding tasks for the project manager. Within every chapter one or more stories to explain the theory.
The first section – Planning the project – focusses on the preliminary planning and the detailed planning. It starts with the need, objectives and the stakeholder identification and involvement. Based on assumptions and constraints the project lifecycle is defined and a work breakdown structure and rough estimates are developed resulting in a preliminary work plan and risk identification (NB only threats no opportunities). Next, the project is broken down into tasks and dependencies between tasks are identified and task constraints are determined. Resources are identified and allocated to tasks. As a final step a risk management plan is developed, and the baseline plan is finalized.
To control the project you need ongoing, periodic and special controls. Ongoing controls are task controls based on the work plan, routine task, resource, deliverables and quality controls and permits, authorization and approval controls. Periodic controls on quality, schedule and critical path, budget, milestone, give & get, tasks, changes and risks. Goal and gate controls, evaluating priorities, issues, estimating project completion and lessons learned are special controls.
The last part – Communication in the project – focuses on formal and informal communication. In total twelve (!) different types of formal meetings are explained. Next the reasons behind and the participants of informal meetings are described as well as the development of informal communication channels and the execution of informal communication itself.
In the appendices a task checklist for the project manager, a glossary and an overview of excluded topics (NB to exclude financial topics, e.g. cashflow, life cycle costs, financial analysis and ROI and say that all financial matters that are essential to the project should be referred to the financial manager, is a little bit too easy. For me a project manager must be able to build and maintain a business case to substantiate continuous business justification).
Throughout the book you find many references to practical tools to be used in your own traditional project. On www.beingaprojectmanager.com (NB the link in the book isn’t working) you can download 23 Word, PowerPoint, Excel and MS-Project templates.
Marisa Silva asked me to review her book ‘Bedtime stories for project managers: and others with trouble sleeping’.
It is a nice little booklet where you will get eleven fairy tales and a comparison with project management aspects, a theoretical explanation, the morale of the story from a project management perspective and how to cope with this aspect via a process, procedure or techniques and you will get references to related literature. It’s easy to read, it will fresh up your memory regarding the fairy tales and it give some food for thought as a project manager.
The following fairy tales are discussed:
The fairy tale
The project management perspective
1
Emperor’s new clothes
Executives believing in their own weak business case (and are influenced by cognitive biases, pet projects, political games)
2
The stone soup
Keep the project scope creep under control
3
The three little pigs
the project manager’s risk appetite and risk management
5
The chicken and the pig
are you involved or committed?
6
The little red riding hood
Follow the critical path
7
The six blind men and the elephant
As a project manager, you need to hold a holistic and integrated vision
8
The wolf in sheep’s clothing
Watermelon reporting instead of transparent and honest reporting
9
The old man, the boy and the donkey
Impossible for a project manager to please everyone
CRC Press sent me the book Modeling, evaluating and predicting IT human resources performance by Konstantina Richter, Reinier R. Dumke for review on my blog.
This book is really for the experts in the area of performance management. I don’t count myself in this area so a complete review is not possible from my side.
The starting point for this book are the numerous methods that exist to model and analyze the different roles, responsibilities, and process levels of IT personnel. What is lacking, and this book fills the gap, is to include the rigorous application and evaluation of human errors and their associated risks.
The authors presents an evaluation approach based on available research and enhance current approaches through strict usage of software measurement and statistical principles and criteria.
Chapter 2: Software risk management and human factors. It starts with an overview of risk management development and an overview of risk management methods. The last part focusses on human errors, mistakes and failures.
Chapter 3: Software engineering, team, and responsibilities. Besides a complicated analysis of risk involvement in the development process you get insides in the different organizational structures (following PMI) and an overview of roles and responsibilities (personal and technical competences) of the following functions: Project Manager, Team Leader, Business Analyst, Software Architect, Software Developer, Software Tester, and Quality Engineer.
Chapter 4: Discovery of IT human factors. This chapter uses the Failure Mode and Effect Analysis (FMEA) over the different functions as described in the previous chapter and will give insights in the different human factors.
Chapter 5: Definition and evaluation of IT human factors. This chapter starts with the explanation of the “Big Five” theory. The Big Five factors (OCEAN) are Openness (intellect), Conscientiousness, Extroversion, Agreeableness, and Neuroticism (emotional stability). As a next step these five are matched with the IT human factors.
Chapter 6: Model development for IT human performance prediction and chapter 7: Experimental validation of predictive model for IT human performance are for the (statistical) experts only.
Conclusion
None from my side because I am not the expert in this area. The reason I put it on my blog is for the chapter on roles and responsibilities and the FMEA over these functions. This FMEA could be helpful for the sponsor to keep the PM under control or for the QA reviewer to judge the human factors, too.