Leadership - Be positive - project management
Be positive - project management
Project management
Process based
Management here is about the process of organising tasks, resource, timing and the quality of the finished article against the management of risk.
These topics are discussed in a lot more detail in ‘The Complete Project management package’ and ‘The Complete Risk management package’.
In a project management sense ‘risk’ and ‘issue’ are often confused and could be better defined as.
| Risk: | A potential event that may have a detrimental affect on time, cost, quality and deliverables. |
| Issue: | This is an unpredicted event that requires a decision otherwise a negative effect on the project may result. |
Problem statement
The reason for any project is that it meets a need. Without a need there would be no project.
The corner stone of any project is the ‘problem statement’ it defines what you are trying to solve in order to meet the need.
It is important that a project team agree on the problem.
If there are no hurdles in getting from A to B then there is no problem, only a goal.
It is rare that a problem will only have one solution. So, at some point, several strategies will require review to identify the best one to solve the problem.
This can be carried out by using the SWOT technique.
It’s a good idea to start with each person writing down an independent summary of the problem.
Individuals should then question this more widely by coming at the problem from different angles e.g.
Think of another way of defining the problem.
What are the key factors?
If I only had myself to think about how would I do it?
If there was nothing to hold me back I might approach it this way.
From a different point of view the problem could be like this.
A completely alternative approach might be.
The aim of these questions is to encourage lateral thinking and get away from traditional concepts.
Each individual having asked him / herself these types of questions should then revisit and modify their original Problem Statement.
Another simple technique, yet quite effective, is to take the ‘problem statement’ in an apparently finished form, and ask the question, ‘why?’
You keep asking ‘why?’ to every answer until you feel it is impossible to go any further.
Hopefully, at this point you will have found the true problem.
Probably a cause and not a symptom.
Eventually, you can write a Problem Statement based upon the individual views having agreed upon any areas of difference.
The ‘problem statement’ can then be recorded in a ‘project notebook’.
Personnel
Without good people the project may well be doomed at the start.
In particular, two areas are important.
The first is the project team who will be coordinating all of the activities.
The second is the person who is responsible and accountable for authorising the project, that is, the project sponsor.
The higher the latter is in the organisation the more likely it is that you will get full support.
The more powerful the leader you work for the easier it is to get irritating problems resolved, especially political ones.
Even if the project fails, at a high enough level it is likely to be dressed up in a cloak of success and learning experiences.
There must be enough authority to gain complete commitment for the project. You really want something that would be a great feather in the project sponsor’s cap. Think carefully, if you have the choice, about what project you take on. If commitment is lacking you may lose the plaudits for any success, which may go with the sponsor, and end up with the blame if it fails.
The project team itself may have a few weak links and you may need to improve the skill set by training.
This may take the form of formal courses or a coaching style.
Ideally, you want a team that are experienced enough to fully delegate tasks to.
If you can only get inexperienced team members it could be because the project is not considered that important.
Work Breakdown Structure (WBS)
Simply put running any project is merely carrying out a series of tasks until you get to the end.
Deciding on the tasks is the key feature. The aim is to start at the end and identify all of the tasks leading up to the completed article.
The way the tasks are identified is a matter for individual and departmental expertise.
Any project, even a home project, for example, planning a holiday, could be done in the same way.
Ideally, you will have a project completion end date that you wish to achieve and a specification for the finished product that you are trying to achieve.
In a big project you will not get away with a simple series of tasks there will be task overlap and dependencies.
You will decide on the nature of the task, the number of personnel involved, other resources and the overall time it will take to complete it.
Within any work break down structure there will be a minimum number of tasks that you will need to complete to get to your goal.
this is called the Critical Path. Any movement of the end date of tasks on the critical path will delay the product completion.
Management of these tasks requires the implementation of monitoring processes.
There will be plenty of opportunities for things to go wrong and a positive mentality will be vital.
In particular, a ‘no blame’ culture has to exist so that you can catch any problems early.
A leader will not accept a delay without discussing option.
Can we get the task back on track?
Can we catch up time on another task and get back on track?
Can we run some tasks in parallel to save time?
Can we add extra resource?
Can we do things in a different way based on current experience?
Can we out source some of the activities?
These are just some of the simple ways to look at getting back on track.
Even here you must consider the problems of implementing the next plan.
For example, out sourcing will have plenty of monitoring problems.
You must display a ‘can do’ mentality. If you don’t, delay will become inevitable and even expected.
Clearly, the project end date should have a degree of slack in it to allow for possible delays.