As a Project Manager, I usually refrain from asking people to work harder… I prefer to invite them to think harder!…
May 15, 2011
September 23, 2010
I sometimes have discussions with people who are facing challenges when dealing with their Project Manager. Here are some tips that one may find useful.
I hear you say:
- The PM is shallow. He has little knowledge and understanding about what we’re doing.
- The PM is bossy. She wants to decide about everything.
- The PM is phony. His thanks are over the top and patronizing.
- She takes my work and run it around without asking me. It’s not even finished.
Project Managers are drivers per character. This means that they are doers and they want to:
- be in charge and in control
- be centre of attention
- be respected
- get things done
They are good at:
- organizing things
- checking and following-up
- persisting and pushing
- getting the job done
- focusing and delivering
- quick to get it and quick to make decisions
They are ambitious and competitive. They tend to fight with other drivers. Their worst nightmare is to lose face (e.g. be proven wrong in public). Of all the characters, the drivers are the ones who know themselves and others the less, on average. They have difficulties listening to others. They like and need support. Drivers are usually protective of people who support them.
In the IT industry, Business Analysts and Developers can be perfectionists. This means that they dislike being put under pressure. They like to be given the time to do things properly. They judge people by how much they know.
Project Managers usually aren’t perfectionists and no matter how much they know, they cannot know as much as all the individuals in the team. Drivers judge people by how much they do.
Get to know your PM… In order to help improve the relationship with your PM:
- You may want to take on yourself to improve his knowledge and provide information in the form of summaries where you can. Team Wikis and/or regular information emails can yield good results.
- Try to influence her while letting her make the decision. Don’t put yourself in opposition to her decision, especially not in front of other people. Tell her that you will think about it. Then later, without witness, argue your point by providing additional information, and allow her to change her mind while saving face.
- You will impress him by responding promptly to his requests and volunteer feedback on progress for longer assignments.
- Keep her informed as to how much work you’ve been doing on a regular basis. It can take the form of daily emails for example.
- Don’t tell long stories. Get and stay to the point.
Tips for the PMs:
- Endeavor to know yourself – you will always be “bossy”, but you can be refined instead of in your face. Read about the different characters.
- Endeavor to know about the project and what the team is doing. Read and read some more.
- Trust and empower your team… Refrain from deciding all the time. How do you feel when your Manager wants to decide about everything?
- Good Managers are flexible and understanding with their team. They know how to avoid hurting the motivation of team members.
September 19, 2010
I’ve gathered in this article a number of reflections based on experience in difficult workplaces, which may be helpful to someone trying to succeed or simply survive…
- When someone fiercely criticises others, including yourself, on a regular basis in meetings or when making presentations, this means that this person is lacking in self-confidence and is likely to be under a lot of pressure themselves.
On the spot, address the criticism. It does not matter if you’re right or wrong. Just don’t let him or her get away with it. Confront them assertively.
For next time, invite the person officially to contribute feedback in private, before the meeting or the presentation. Give them a lot of importance and the opportunity to comment once for all. Once they’ve been involved officially and their name is on the paper, they will defend it.
- Kindly doing deeds for a person that is negative towards you, even when you don’t feel like it, will make them feel they owe you in return and is very powerful to make them change their mind towards you.
- Being loyal to a manager means resolving misunderstandings or conflicts with him direct and in private, always, even when it requires courage. Speak openly. Expose your feelings. Never seek help with his manager or anybody else. In case of a heated argument, it is recommened however to wait until things have cooled down.
- When a document needs to be reviewed, ask your manager if he/she wants to review it first, even if you think that they are busy or they’re not interested, as they may cope some of the blame if the document is to be criticised.
- Introduce yourself spontaneously to people you don’t know in the workplace, show interest and make them feel welcome. They will have a lasting good first impression. In the contrary, they might develop uncertain and uncomfortable feelings towards you, especially in a difficult workplace.
- Be assertive and firm with agressive people. Stand your ground. Respond however to attacks with the same intensity, not weaker nor stronger. It is a difficult equilibium to achieve, but the only one that may yield positive results in the long term.
- Avoid complacency and look for opportunities to learn and improve all the time. Read, read and read some more.
- Prefer face to face or even phone to email. In any way, don’t send an email to anyone with your boss or his boss in copy, unless it is a complement or very positive feedback. It will most likely be received as an attack on the other side, whatever your intention was in the first place.
- If you are to give negative feedback about someone, make sure there is at least one person with some influence that is of a similar opinion. Be also very mindful of people networks.
- If you suddenly feel uncomfortable or somewhat embarrassed when having to express yourself or make a decision, it is a sign and one should trust his/her gut-feels. Take the time to understand where the feeling is coming from first, in order to have a clear view.
- Evaluate the tasks that are given to you conscienciously, using your values in life as a reference. It is OK to decline to do some things based on your values.
- One needs to have a good relationship with most of the managers above, in oder to have a chance to be promoted one day. This will be consolidated however by the good relationships established with the rest of the staff.
- Respond to emails… acknowledge reception first if the reply is to take more than a couple of hours. Don’t let them wondering.
I also recommend the book Coping with Difficult People.
Finally and in general, it is recommended to stand on the side of over-communicating with kind and polite manners all the time.
March 27, 2010
When reporting on earned value, more often than not, the project is slightly behind the original plan and the earned value is below the planned value.
How does the project manager and the project stakeholders know if the variance is within the tolerance of the project or not? What is the bottom-line?…
The project critical path can be used, in order to represent the tolerance threshold, as in the example below.
Values for the chart can be automated using MS Project and MS Excel… See previous post on earned value calculation http://www.casoft.com.au/2009/04/calculate-earned-value-with-tfs.html
For more information contact us – jjacquet AT casoft.com.au
March 7, 2010
With a waterfall approach, one wants to have as close as possible to 100% of the requirements up-front. The challenge in this case is fairly obvious. Getting 100% of requirements documented on a fairly complex system is no easy task and is rarely achieved in practice.
With an iterative approach, I will kick-off the development with 80% of the requirements up-front. Knowing Paretto’s (80%-20%) rule, it makes a lot of sense! The rest of the requirements can be elicited during the development, and a lot of time can be saved this way.
If an Agile approach is to be implemented, I will start the development with less than 20% of the requirements and the scope being defined. In this case, on basically unearth the requirements by putting prototypes in front of the Customer and getting feedback. The prototypes are refined as the development goes, and become an application overtime.
January 17, 2010
One may notice that everyone, in every area of life but more so in project management, claims to be successful and, more often than not, successful only…
How good someone really is, who has never experienced failure, I ask?
We all have strengths and weaknesses, and this means we perform better in some situations than others.
Have you ever noticed that when their is a problem (and there’s always one), most consider self as being outside of the problem, while everybody else considers you as being part of it?
Successful people take ownership of the problem at hand…
September 12, 2009
Components Based Architecture has been formalised and publicised by UML-RUP more than 10 years ago, and the benefits of this approach are still unknown or under-estimated by most.
It escapes me how, in the 21st century, enterprises can ignore the return on investment (ROI) that can be achieved with components.
The most commonly missing piece in the software engineering puzzle today is the architecture document. I keep seeing projects after projects documenting detailed designs after gathering the requirements and no architecture.
When no components based architecture exists, Managers are reduced to finding and selecting solutions at project level.
With well documented components, encapsulating meaningful functionality, it is for example possible to:
- Find Commercial-Of-The-Shelf (COSTS) solutions for one or several components.
- Outsource the development of low added-value components.
- Reuse components from other applications within the company.
Components are however a science and there is more to it than what meets the eye…
See previous article RUP – Component Based Architecture
July 1, 2009
About Scrum we like the philosophy and the following practices:
- Feature prioritisation sessions
- Undisturbed iterations (called Sprints)
- Functionality presentation sessions
- Self-organising teams
In a nutshell, SCRUM principles are as follows:
- All management responsibilities are divided between 3 Scrum roles:
- The Product Owner focus is focused on Return On Investment (ROI)
- The Team is responsible for developing functionality. Teams are self-managing, self-organising, cross-functional and they are responsible for figuring out how to turn Product Backlog into an increment of functionality.
- The Scrum Master fills the position normally occupied by the Project Manager. He is responsible for the Scrum process. Like a sheep-dog, he’s responsible for keeping the flock together (focused) and keeping the wolves away (undistracted).
- Each Sprint is an iteration of 30 consecutive calendar days
- A Sprint starts with a planning meeting, where the Product Owner presents the highest priority Product Backlog (4 hours) and the Team plans out the Sprint (another 4 hours).
- A Sprint finishes with a Sprint review meeting (4 hours), where the team present what was developed. Then the Scrum Master holds a Scrum retrospective meeting with the team.
- A Product Backlog lists the features with estimates, associated Sprint and remaining work (days) – maintained by the Product Owner
- A Sprint Backlog lists the tasks, which the team defines for turning the Product Backlog they selected into an increment of functionality, associated with the Originator, the person Responsible, the Status and the hours of work remaining – maintained by the Scrum Master -No Gantt-chart
- A fairly complete set of rules can be found here: http://www.agileadvice.com/archives/2007/05/scrum_rules.html
For more information, get the book form Ken Schwaber – Agile project Management with Scrum – click on the image below: