Project Management: neither difficult nor complicated

Managing any kind of project is never difficult!

Anything is only difficult, as long as you do not understand what your task is, what is the situation, or if you omit vital prooven successful steps. There can be many challenges in a project, but to state, that it is difficult always makes me important and implies that I am better than you.
The project manager is always getting blamed if things do not turn out as expected, no matter what the reason. But if you know that this is a part of the job, you handle it like a father handles his emotional children. You see it, understand it and treat it with a smile.

The solution to „constant heat“ is to establish excellent communication. To the degree you can get excellent communication going, you will achieve the goals of the project.
Technologies are changing. Look into the tools you use today, the methods used, and the demands arising. Unfortunately, people think that if they have done training, they know what project management is all about. No certificate will be replaced by what has been proven successful, and that what makes it successful is „experience“.
Exercising daily routines is a part of the job. You have to define what you have to execute daily.

Note

The following is a list of good practices. They do not contain medicine for any project sickness you might encounter. Use these items, so they support you in archiving the goals.

Daily Tasks

• Talk to the people!
  A daily „hello“ a regular „I am here“, the daily I care of you and the coffee/cigarette / chat you have on the floor and in between will give you most of the information you need to get your job going. These chats supersede the most meeting outcomes.
• At least one hour a day for training.
  Even though you have one hour less time to execute the job, this hour typically results in more efficiency or higher quality.

Tools: Whats project management about

Project Management is not about drawing beautiful charts and graphics to present to the stakeholder. Neither it is using sophisticated tools. It is about „Keeping a group of individuals aligned on a target and make them work as a team“. No tool will help you if you do not have the skills to execute the processes and the methods. So if someone rushes in and tells you that he found the tool that will handle your problems, be aware. 

“A fool with a tool is still a fool.”

If new methods and processes get pushed into the market, the people implementing these often tend to forget the proven basics of success. The correct action is to take any original method or process in if it seems to be suitable[1]But do not throw overboard all established success factors, and: „Kick it out if it does not suit“[2][3]

When initiating a new project, study this list of successful practices to see which ones would be valuable contributors to that project. Norms/Standards, such as ISO or IEEE, contain condensed knowledge; therefore, I strongly advise training on that regularly. Build the corresponding activities into your thinking and plans.

[1]. This approach is, by the way, an old engineering principle and as well very agile.

[2] An example of that find in the PIM (Process Improvement) of Automotive SPICE®

[3] See as well a study on agile by Kugler Maag www.kuglermaag.de/fileadmin/05_CONTENT_PDF/2-22_agile-automotive_survey-2015.pdf.

Familarity with the scene

Projectmanagement is always very similar – you just have work the list off.
Experience can be exchamnged by experience.
So the more you have done, the more you knwo how – and how not.
Stay focussed on „how“.

Certificates

Look up the Link

If you think that a certificate will give you people that have abilities, you are done.
Certificats just document that you have someone who has passed an exam.
If he is just knowing it by heart, or if he can implement in life are 2 different things.
Experience can be exchanged with experiance

Basics to any project

S.M.A.R.T

Is not just a word in ordinary language, but a word to use in project management.

Define the project goals and then define the project success criteria.
No goal(s) or unclear goals means that you have no chance to achive anything.
One major part is always to have the data in writing and ensure they are understood. Ensure that your wording follows the „rules of requirements“.

• Specific – target a particular area for improvement.
• Measurable – quantify or at least suggest an indicator of progress.
• Assignable – specify who will do it.
• Realistic – state what results can realistically be achieved, given available resources.
• Time-related – specify when the result(s) are achievable. (Source)

At the beginning of the project, make sure all stakeholders share a common understanding of the goals and the success criteria.

Often this part is omitted, and the tendency is to start fast, so be aware:
A goal is like the destination of the journey, and it shall be an archivable objective!
Success criteria could be something like „achived in time and budget“ and no matter what definition is you us in your company, get them defined.

Stakeholder Analysis

Begin your project by identifying your stakeholders and their interests and expectations.  Watch out! Project managers and management tend to see only the business stakeholder and tend to forget the staff that is to execute. If you want to stay in command, you need to understand the workloads and constraints of your team and supplier as well and keep them in the loop.
“Clients do not come first. Employees come first. If you take care of your employees, they will take care of the clients.” Richard Branson.
Get them written down and agreed. Next, define some clear and measurable business goals. Some examples are:

• Increasing the speed of the application
  _{by 10%. Don’t take any global words that are not measurable like „sufficiently improved“. Define the constraints.}
• Reaching a specified sales volume or revenue
  _{That value “specific” has to be a number.}

Every request shall have acceptance criteria, so you know what needs to be done to state “done” _{Example is the „Definition of Done” in the agile development.}.
Ensure that you know the constraints that apply to the project. These constraints can be weight, speed, ambient temperatures, budget, legal time, and international standards to be used to and so forth. Omitting those constraints will lead to increased workload and stress during runtime. If you insist on these data: In the beginning, it might cause stress here, but that stress later is manifold to what you have in the beginning.

Prioritise

If all is equal, you won’t be able to work. So prioritise!

RTS – Read the specification

Create and or read and UNDERSTAND the specification.
All those involved on the top level have to understand the needs as defined. If you encounter questions later in the project, you can almost certainly state that one of the concerned did not understand. As a pilot (or a project manager), you do not need to know how to build a turbine.  But you need to be able to understand what is to be achived – where you have to land. As a pilot you would not start if you do not have sufficient fuel on board, neither would you choose a jet if you need a helicopter and vice versa. Take the viewset of a pilot in command and act accordingly. Do not start if you know that one of the following points is not aligned.

1. Finance
2. Staff to execute
3. Schedule
4. Equipment
5. Goals of the project including Quality objectives

To the degree you have uncertainties on these goals, you inherit risks. (At the end you will find a List of Standard Project Risks to take care about)
Some of the items you encounter will be enhancements to the project. Some will be constraints. No matter what. You need to keep in mind that the most significant improvement comes from motivated individuals. So treat your colleagues in a way that they are supporting.
If there is no degree of freedom for you to act on, you will be not able to manage. You will be a slave. And even worse. As you choose to be a slave, you will inherit that mindset that will lead you to be a slave in life.
Again take the viewset of a pilot.

• What happens if we do not land on the desired airport (Target)?
  • You will delay doe to unsufficient (Staff, Equipment, Finance)  and have to make the trip longer.
• Can you deviate from the plan if a thunderstorm crosses your way?
• Can you reorganize planned targets in case a situation comes up?
• What are „MUST haves“?
• What are „Do not want to haves“?
• What are „Nice to haves“?
• What are trivial targets?

Be aware that all these actions are not „carved in stone“ and may change. If they change too often – realign with stakeholder needs.

Define your samples and the content

Not everything is agile, and you can adjust on short term needs. The smaller the team, the faster you might be able to act. If you fly an Airbus 380, your curve will have a considerable radius, compared to an Ultralight. Some features are depending on each other, and, i.e. a safety feature comes first and may override design. So only fly in terrain you know, else prepare for a jungle.A bootloader is needed before the rest can operate correctly.

As stated above, you will have quality targets you have to meet. A list of criteria shall exist for every sample that is to be delivered.
^{These release criteria are to be a part of the contract/requirements.}

• There are „no open high-priority Defects
  High Priority defects“ has to be defined and made measurable.
• ample contains planned Functionality
• Performance goals achieved on all target platforms.
• Specified goals met.

Whatever criteria you choose, everything has to stay SMART, as stated above.

Negotiate.

One of the abilities of a project manager is to say „NO“ to whomever. Reliability is one of the utmost confidence drivers. Commitments you can’t keep will get you into a dwindling spiral of justifications, and you will have a tough time to come out.

There will be issues arising that can’t be done. Most targets can be achived. Like: „You can have that feature but not that“. Do not fly into a storm! Avoid it if possible. If you are thinking ahead of your plan, you will already monitor things and developments that might be an impairment or an enhancement. If you are in communication with all those who are affected by the project, you will see these things coming up, and even if you land different as planned the concerned will be happy with what you did.

So the „negotiation“ can be done in formal actions. I prefer the negotiations at a coffee break. Besides the fact that the talks are much smoother, these „negotiations“ are done on the run and thus do not cause any stress to those concerned. They enhance understanding.

If it comes to “hard negotiation” you should ensure emotions stay out. If they are in, get them discharged, before you start and then:

· Look for solutions. (Do you have a problem or are you the problem)

· Focus on archiving the project goal(s)

Any experience gained from previous projects will strengthen your negotiating skill and position. Communication shall be done with reliable data. Fact-based logics supersedes any emotions, except if you are fighting against unreasonable people.
Those you shall fight, and you should ensure to get that person off the project.

If you continuously keep all involved parties updated on things happening in the project, negotiation is typically very smooth.

A project shall include project completion and project cancellation criteria. If these cancellation criteria are met, get to the nearest possible landing strip and stop. Before it comes to that situation, ensure that you do those actions that provide confidence for a safe landing. Maybe those concerned are happy with 90% of target met

PLANNING THE PROJECT

Sense and Nonsense

No plan will survive the first contact with reality; neither is it carved in stone. That does not mean that writing a plan is nonsense. A plan is a layout for the future.
An original plan does not need to be very detailed. The plan shall contain milestones, and then top-down the classical items:

Reading and understanding all related issues

1. Assumptions
2. Actions to be executed
   1. Requirements
   2. Review
   3. Renegotiation
   4. Developing
      1. Every concerned domain
   5. Testing
   6. Correction
3. Roles executing
4. Equipment (Software, Hardware, Mechanic) needed
5. Supplier selection and management
6. Travel
7. Funds
8. Monitoring
9. Metrics

The beginning shall be at least a rough draft. Develop it once and then reuse as a template to check that all must-haves are inserted. Make a plan that contains 150% or more of what is needed, and then strike-out what you do not need. Update this template with data out of the retrospective (see below).
Do not make everything perfect in the first shot. Make it suitable and then:
Run what is there and establish what is needed.

Basic Plan Approval

Ensure that you get an okay from the stakeholders to execute. Don’t take the brushoffs. Ensure the plan is read and understood, if necessary check each item inside with the responsible person to ensure understanding.

Detailing the plan

After approval, everyone wants you to start right away. However, here the work begins. Every involved domain needs shall be considered and make a very detailed plan. The detailing degree you do depends on the level where you operate. Every domain involved is to detail their actions and deliverables; you shall merge them. Still, everybody has to be the master of his plan. The right method of how you combine them and the tool might come into view here. The detailing degree is like the checklist a pilot or the engineer uses. For each level, it shall create a clear roadmap of actions to be done and include feedback/correction loops. Get the responsible for being „in command“ of the work that he executes.

Detail approval

If that plan is now established in detail, you will find that there will be discrepancies to the first draft. Depending on the now adapted and aligned version of that plan, you decide whether it is necessary to resubmit for approval or what communication to the stakeholder you do.

Kick-off

Now get everyone together and brief them on the goals, the constraints, their rights and duties. Ensure that you get a real agreement from those and that you handle any concerns.Handle any objections, or replan unless all stakeholders are aligned and in agreement. This kick-off is like handling the preflight checklist. Go through all items and ensure you can mark them as „checked and passed“ and no roadblocks popup that would prevent a promising start.

Reuse

In every project, there will be tasks that „are the same“. For all those activities you can develop “a standard plan” a standard Checklist and a Standard Timing

Rework

At the end of all significant steps in a project, there shall be a review. A review is a quality action. Testing. People tend to plan, assuming that everything developed is okay. Not all tests will „pass“. Based on the experience in your company, a certain amount of failures and the needed loop time to correct shall be planned. In safety- and security-related matters, a failed test can be a roadblock. So go ahead and implement these loop times after every quality-related action. (Review, Test, etc.)  Companies typically enforce planning for best, realistic and worst-case scenario while assuming the best case always happens. If you have experience in the company, you will be able to predict the resources needed if you have a similar product. Be aware that any project you do in an „unknown terrain“ will bear risks you never thought about and will bear challenges never seen before. So plan realistic buffers.

Risks

Who is in command? If you don’t identify and control project risks, they’ll control you. For all those standards, you use checklists in aviation, or you regularly train the pilot in the simulator and challenge him with risks that you are aware of what they might encounter. Those simulator rides are always doing things together that you in normal life think you will never meet. If you are trained and aware of these risks, you have a particular alert state and will act early to avoid a crash. So don’t take that risk management in a way „it might not happen, so why care about“ but instead – let us see what all can happen and what we will be doing if it happens.  Identifying the possible risks isn’t enough. You also have to evaluate the relative threat each one poses and as well how you will be handling those if they occur. Do this analysis for each risk that you identify. See as well at the end the „Table: Risk List.“

PIM Process Improvement

„We do it that way since“ and „We are different“ are the killer arguments for any change. If you want to become more efficient, you have to look at how you want to make it more efficient. Kaizen is one of the things – do not over-allocate your people. The allocation shall be 80%. Now you will hear people saying that this 20% is a waste of workforce while it is the opposite. Small chats with colleagues, rereading or studying known or unknown things will broaden the view and enable your staff to be more efficient. And let the team do it. No „Process officer“ knows all the operative work. A staff coming with a suggestion is one of the most valuable people you have. Utilize their knowledge and enthusiasm to improve. Quality is to ensure that the purpose of the process is kept, but the rest is to the people.

The process improvement is like upgrading the plane. You can not fly during that time, but you shall be faster, or the quality will be better. No other interest shall be involved in process improvement.

Estimation

Estimate your schedule in terms of hours used to execute the task. Some times over-exceeding the standard work hours is needed to meet a target. No one will ever work his working time without any interrupt. If you planned well, these interrupts are already in the schedule. Meetings are disrupting the work but necessary for coordination. The better the toolchain and the better integrated, the easier the sessions will be. Much time is spent on ensuring data consistency. The larger the team becomes, the more coordination is needed. Deduct this time spent from the max workload that should never exceed (xx%).

Take int account that there is no linear increase in task execution if you add people there. 100% more people does not imply 100% more work can be done.

Overloads

Commonly people are allocated to several projects. 400% workload as every project manager assumed he would have the resources at 100% have been arising.
Besides: The person who is working in several projects will have to switch his mind. Thus, if you have people working in several projects take into account, that during the assigned time, the effectiveness of the person will be reduced. An excellent tool will show you over allocations across projects. 

Training

One part of the project manager is “Ensure required skills, knowledge, and experience”. The above implies that besides the above already mentioned training, you plan as well for the improvement of skills needed for the staff executing. Besides the fact to take into account the average values for vacation time, sick time, and so forth treat training time the same way.

If you want to have your staff ahead of arising issues, get them trained. While training is typically an action initiated by human resource or quality, please add some more. Any knowledge gained, leads to a happier and thus more efficient person, and that is what you need.

Documet the Data

When you prepare estimates assumptions and whatever, report why the datum you have is in the way as it is. You might have the experience, you might have asked someone, or you used any method to derive the datum. Assumptions and constraints and as well methods may change, and thus a change for that item will be easier to understand if you have to rework. The best way is that you create a checklist or a method that is applicable in your company. Please note that these estimations are typically considered as an annoying work, leading to false estimates. You will find many methods exist for, i.e. software and only a few for system development. „Project Cost Estimation“ by Deutscher Mittelstand is a method based on the number of artefacts you receive.  The respective times needed for an artefact in that class in your company, the quality actions based on an artefact and the distribution factors (multiplication/compression factors to the next object class). It is suitable for any project and is a method based on statistical values in your company and independent of the method used.

Plan the unplanned

No plan survives the first contact with reality. Things arise – changes happen, and you’re your plan is out of date the moment you start with it. Take risks and their implications to derive a buffer for the unexpected.

Record Dones

Record actuals and estimates.

To improve for the future, go and document time and resources used on a task and enforce people to do so as well. Having a good toolchain people will be able to record what is happening, you will stay ahead of what is happening and will see if tasks are running out of allocated or are better than expected.

Done is done

Progress reports are helpful and suitable if they are filled with actual data. If you planned to a granularity of tasks not exceeding 20 hours (8 is better), you would be able to have real monitoring. To avoid the stress of being out of schedule, people tend to report better. Besides the fact that this stress should never happen, you shall derive precise handling with the data and shall have a tool that will evidence Dones (i.e. Staus engines, Frozen or baselined data, etc.).

Process improvement – Retrospective.

The retrospective is the word used in agile software development to describe a short review that is executed at the end of each sprint. It is the reflection of what was right, what wrong, and so forth. For sure you can do that in any other way at any time when it seems suitable. The intent is to learn from the past and get all the right things embraced. Get them fed into the organization and to ensure that not so good things do not happen again.

And finally

The above will not be handling everything that you encounter, but it will cover the most fundamentals. Use it to become better.

Standard Project Risk List

1. Availability of Staff in the Office – Distributed Worldwide work
2. Risk out of Software /Hardware / Mechanical development on module level
3. Person Hours exceeding
4. Estimated Project Schedule
5. Team Size at Peak exceeding 20
6. Number of Interfaces to Existing Systems Affected
7. Project Definition unclear
8. Narrow Knowledge Level of Users
9. Project Scope Creep – à ensure proper Change management
10. Consultant Project Deliverables unclear
11. Vendor Project Deliverables
12. Cost Estimates Unrealistic
13. Timeline Estimates Unrealistic
14. Number of Team Members Unknowledgeable of Business
15. Steering Committee existence
16. Absence of Commitment Level/Attitude of Management
17. Lack of Commitment Level/Attitude of Users
18. Absence of Mid-Management Commitment
19. Project Staffing – overallocated resources
20. Project Team Availability
21. Physical Location of Team prevents effective management
22. Weak User Participation in Project Team
23. Project Management
24. Steering Committee existence
25. Staff turnover
26. Methodology Used foreign to the team
27. Change Management Procedures undefined
28. Quality Management Procedures unclear
29. Software Vendor
30. Number of Times Team Has Done Prior Work with Vendor

Agile

We are Agile – we don’t need that. Please reread especially the right side of the Manifesto for Agile Software development if you encounter this kind of attitude

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Planning with SEQ.IST

And you can plan any kind of process and method with SEQ.IST – Check it