Project Management 3.0
It seems it became a fashion these days to put version numbers to everything. When I saw Bas de Baar‘s post with the title Project Management 3.0 I was first shocked. Wow, how could I miss the all those versions?
But in a while, after reading his post and the article he cites I started to realize that there is nothing new under the sun – it’s just a new, fashion name for the thing we already know.
Obviously, the version numbers 1.0 and 2.0 were created by the agilists. To put it roughly, PM 1.0 refers to the classic or heavy methodologies in project management. They focus on large projects, large budgets and big teams. Ugly Gantt charts, many stakeholders, horizon and beyond timelines and (note!) expected failure! PM2.0 respectively has only positive characteristics: small teams, made of smart and motivated people (does it mean that the large projects are performed by dumb people?), fast pace, feedback, responsiveness, etc.
It smells like a religious war from very far and isn’t worth mentioning. As Glen Alleman says in his blog Herding Cats, if you want to show the advantages of the agile methodologies you shouldn’t compare it to Waterfall because “Waterfall is dead, dead, dead“. The modern version of the “classic” PM approaches like PMBOK and Prince2 also embrace change and calling them “heavy” or “rusty” is not relevant anymore.
What caught Bas’s (and mine) attention is the idea of “Social Project Management”. As he states:
The Project Management style, and the supporting tools have to be “social”, and now more then ever. The project landscape is turning mobile, multi-cultural, 24×7, highly distributed and in ever flux.
But this situation will increase the risk of getting into some social “booby” traps and he points out the three most important ones:
- Communication trap: proper understanding of what the other stakeholders need in the project;
- Trust trap: letting go of control and hoping people still do what they are supposed to do;
- Isolation trap: no sense of belonging to the project through geographical, cultural and timezone differences.
This is the Project Management 3.0 and the real challenge for it will be a social one. According to Bas, this is the place were social software can help a lot. Not only in collaboration but more in building a sense of community, enhance trust and stimulate open communication.
You can read his entire post here.
Filed Under Project Management, Teamwork | Leave a Comment
How Do People Become Project Managers?
The Projects@Work site performs a monthly survey and the July’s questions were very interesting for me because they brought very interesting answers.
Question No. 1: Did you pursue a position in project management or did you “fall into it”?
Answers:
- By choice: 30%
- By accident: 70%
What does it mean? It means that the upper managers still don’t appreciate the role of the project manager. They don’t raise and don’t educate people to be ones. The position of the project manager is still filled “on the fly”, most often by technical persons (in the case of the software development – by senior programmers). I have such observation among some Bulgarian software companies but the results of this survey show that the situation is not much better in the United States either.
I’ve seen another example, too. A guy asks to be a project manager and the upper manager says: “Oh, you’re too ambitious. I can’t allow you to take this position. Tomorrow you may ask to sit in my chair. No way!”
Question No. 2: Did you have formal project management training before your first assignment?
Answers:
- Yes: 15%
- No: 85%
The answers to this question explicitly confirm my opinion that the company management totally neglects the profession of the project manager. They don’t understand the importance of this role and they don’t develop their human resources for that. It seems that the management considers the role of the PM as the “necessary evil” and they have PM’s just because it’s a common notion.
If you pay a closer attention to the numbers you’ll see that the people with a formal training are twice less than the people who intended to be project managers. It means that even among the people who really want to develop themselves into our profession only half of them have the chance to get a formal professional training. It wouldn’t surprise me if there is some data showing that a significant part of the people who had formal training have paid for it by themselves.
Question No. 3: Do you consider project management a long-term career or a “stepping-stone” in your professional aspirations?
Answers:
- Career: 60%
- Stepping-stone: 40%
At the end, the answers to the last question show me that the most of the project managers like their job and they consider it to be their future career too. No matter how unappreciated the profession is, we still like it; it gives us the feeling of doing something important, of significantly contributing to the project’s (and respectively – the company’s) success, of creating something useful for the customer, something that makes their life better.
As I said before, I have some observations among the software companies in Bulgaria but I would like to gather some information “from the source”. That’s why I am asking you – my readers – the same questions (a little modified only to take less space) in order to see if the results are the same in other places in the world. I believe most of you are from Bulgaria but there are also people from all over the world and everyone’s opinion will be useful.
Is it the same in your company? Or in your country? How can we prove that the profession of the project manager is important and that one of the sure ways to increase the probability of a project’s success is to have better trained and motivated project managers?
If you are a project manager or you are somehow involved in project management practices or in software development, or you just have an opinion on the subject, please, answer the questions on the sidebar or send me your comments. I would greatly appreciate that.
Full Time Pay for Half Time Work, Part 2
Since I posted my comments on Steven M. Smith’s article Full Time Pay for Half Time Work? I received some arguable comments and also Pawel Brodzinski published his very interesting point of view on the topic at his blog. So I decided to put some more “food for thought”.
First of all, there is no such thing like “full time salary”. Each employee’s salary is negotiated individually. At least this is the common practice in Bulgaria but I believe that the same method is applied all over the world. The times of the “developed socialism” when all the people had the same salaries are far behind in the past. Currently in the most software companies in Bulgaria the ratio between the lowest and the biggest salary for a software developer is between 2:1 and 3:1. Which means that for a full working day and for 40-hour week one person gets 500 Euro and another gets 1000 Euro (for example).
Why is that? Simply, because one person is considered more qualified and more productive than the other. We know from Steve McConnell’s books that there is a difference of 10:1 in software developers’ productivity and we accept a difference of 2:1 or 3:1 in salary (which I think is not so fair if the productivity is bigger). So why is it so impossible to accept a situation where one person’s salary is equal to another person’s salary but the working time is twice shorter? In my opinion this is quite normal if the first employee is twice (or more) more productive than the second one.
Another point that is not taken in consideration (especially by Pawel): It is not said anywhere that the person is a software developer. The original case is about an employee of unknown specialty. But even in the software development there are several roles that do not require the person to be full time at the office: sales agents, business analysts, deployment and user training specialists, etc. By definition, these people are required to spend a lot of time at customer’s site so they usually don’t stay at the office regularly and their absence will not hurt the team spirit. An employee like Albert in the given example may very well fit one of these roles and be hired on a half time if he is able to do his tasks.
I still believe that if we are flexible enough in our thinking we can achieve better results. We should not obey all the traditions just because they are traditions. We should use them selectively and to pick only those which can help us achieve our goals.
The Project Management Theories According to Bas de Baar
Bas de Baar posted a very interesting analysis of the structure of the project management. He claims that “there is not one theory that explains project management; it is a collection of several fundamental ideas, the theory of project, and theories of management“.
Later on he describes in a slightly humorous way the theory of the project and the three theories of management: management-as-planning, the dispatching model and the thermostat model making this way a dissection of the main principles of the project management, which, however, come from an ideal, theoretical world and sometimes are too far away from the reality.
Great reading! Enjoy it!
Full Time Pay for Half Time Work?
Steven M. Smith in his blog posted a very interesting article called Full Time Pay for Half Time Work? where he shares the case of an employee called Albert who guarantees he can produce the same results as the other colleagues (even 105% of the quote), he is liked by the colleagues and adored by the clients but he wants to work no more than 20 hours a week and doesn’t want to waste his time.
The author asked several managers whether they would hire Albert but all the answers were “No”. No one appreciated the fact that Albert is 100% more productive than the others. All the managers asked felt insulted by Albert’s requirement for 20-hour work and required that he worked for 40-60 hours. In fact they didn’t like the fact that he insisted on his freedom, they wanted to have a tighter control on him no matter how productive he was.
If I had to make such decision I would hire Albert if I have the guarantee that he will produce the promised results. But the answers the interviewed managers gave are frightening me. They confirmed my fears that the most middle managers nowadays don’t have the entrepreneurship spirit at all. They consider their employees not like partners (heading for the same goal) but more like property, resources, or even like slaves. The majority of managers value the most not the productivity of an employee but the ability to obey orders.
I feel we are back in the 18th-19th century…
Read the second part of this posting here.
Top 10 Mistakes in Software Development, According to InfoWorld Tech Watch
There was a post in InfoWorld Tech Watch entitled 10 mistakes to avoid in software development where they quote a Forrester Research report published recently. While I think that, generally, the list of mistakes they published is really important to the success of every project, I will go into more details with each one of these mistakes and will give you my opinion on them.
Here they are, the 10 mistakes we should avoid in software development:
- Never committing to project success. This is too obvious, I don’t see any wisdom in it.
- Freezing the schedule and budget before a project is sufficiently understood. Unfortunately, this happens everywhere, every time. In my opinion, this is the main problem of the software project management: What to do when you are asked to give estimates about the cost and the time, and even to sign a contract before you know what this project is about?
- Overscoping a solution. Yes, this is a mistake but I believe it happens more and more rarely.
- Circumventing the application development organization altogether. I don’t think it’s a mistake if you know what you are doing. Sometimes it is the necessary if you’ve been assigned to a “Death March” project. The real question is: Can you still manage to succeed?
- Underestimating the complexity of a problem. Usually, this is the reason for signing contracts with low budgets and shortened schedules. Unfortunately, this mistake is mostly made by the upper management mostly because they don’t consult with their team. I believe, that every company should invest some time upfront to investigate the customer’s problem ti gain a better understanding of its complexity.
- Being stingy with subject-matter experts, in which their participation is not sufficient. I think this is also a result of the previous one.
- Choosing the wrong project leadership. Or the wrong leaders. Or the wrong managers. Or the wrong customers (Can there be wrong customers?)
- Distrusting managers who have had tasks delegated to them. I would say that not trusting anyone in your team or company is a mistake.
- Jumping into development without enough research. Again, it happens as a result of underestimating the problem.
- Suppressing bad news, in which dialogue is insufficient. Do you know a manager who likes to hear bad news?
Well, some would say that I am too skeptic or that I am a naysayer. No, am not. I think there are a lot of problems in our industry but this is my profession and I love it. I really want to discover the biggest mistakes we make, to analyze the reasons for them and to make a plan how to avoid them. Which is really hard. And when we look at our mistakes we just need to be more specific, especially when looking for the causes of those mistakes.
Filed Under Classic Mistakes, Death March, Software Development | Leave a Comment
The 20 Qualities of the Inspirational Leader
There was an article in All About Agile blog, entitled 20 Qualities of an Agile Leader. Well, the title is a little misleading and the author clarifies later that all kind of teams need inspirational leadership and these are the 20 qualities of the inspirational leader:
- Strong communication – storytelling and listening
- Passion for learning and intense curiosity
- Focus on developing people
- Having fun and being very energized
- Strong self-belief, coupled with humanity and humility
- Committed to making a significant difference
- Clarity of vision and ability to share it with others
- Dogged determination and often relentlessness
- Strong focus on priorities
- Not afraid to show some vulnerability
- Regular use of reflective periods to think and learn
- Real passion and pride in what they do
- Confidence and trust in their teams, giving them real empowerment
- Respect for all (team members, temps, customers, suppliers and directors alike)
- Clear standards of ethics and integrity; openness and honesty
- Ability to drive, inspire and embrace change and continuous improvement
- Positive attitude at all times and an innate ability to be diplomatic in any circumstances
- Lateral thinking and ability to find innovative ideas and solutions to problems
- Ability to inspire and motivate others
- Willingness to take (calculated) risks
I find this list quite comprehensive. I marked the ones I find most important for me in blue. I find them the most important probably because I still need to improve these qualities in me. How about you? Do you agree with all the points? What are the most important ones for you? Do you have all these qualities?
Filed Under Leadership, The Role of the Project Manager | 5 Comments
Classic Mistakes – GigaLease Case Study, Part 2
In the Part 1 of this case study I talked about how the project was set up. Now I’ll continue my story with the project’s execution, the team’s growing up and some truths that we revealed during the project.
Building up the team
I was so eager to succeed with this project so I and the PM pressed the management very hard to recruit more people to build up our team. Unfortunately, they weren’t looking for the best talents but hired whoever was available.
The first new member of the team was Jannice. She was hired by the HR department without asking for our opinion. Anyway, she claimed to be a very skilled and experienced developer (she was my age) but I gave her a very simple task – to create a form with two simple controls and to bind it to the corresponding record in the database. I knew she needed some time to get acquainted to the development style I established so I gave her a couple of days although I could do it in a couple of hours. Three days later she still had no progress and she told me she still doesn’t understand how to do the task. After a thousand explanations and examples, on the fifth day I understood that she has no idea of software development. She was absolutely useless and from that moment on I assigned her the simplest and the least important tasks. I was still alone and I continued my pressure upon the management to assign more people to the project.
Several months later, when we started to write the user documentation and the help system, Jannice told me that she is really skilled to do that and gave her one more chance. Luckily, she was really good and I was very happy that we finally found her place but we still wasted all those months trying to make a developer out of her.
Next hire was Zoe. This time we insisted to participate at the interview so we were able to ask her some technical questions and we understood that although she was not perfect, she was a developer with some experience and with the great desire to learn and to improve.
Zoe was really fast learning and soon she took responsibility on some of the program’s modules. I was very proud of her for she understood the business logic very quickly and soon she was able to discuss some of the requirements with the customer.
Although Zoe was a hit, the work still remained too much and I kept asking for more developers. Soon the management assigned Frank. He was already an employee but he was famous as the company’s “black sheep”. He had no respect for the company’s rules nor the working hours. I could never be sure when he will come to work and how long he was going to stay. He used to play games during the nights and usually used to come to work at noon. Then he worked for some time and about 5 p.m. left to meet his girlfriend.
Frank was very unproductive and was another peer who reported hours but had no real contribution to the project. We worked on VB6 and it was common situation Frank to commit code that wasn’t compilable (VB6 had that feature “Compile on demand”) and to break off the work of the other team members.
I am still wondering why they kept him in the company. He couldn’t contribute not only to my project, but to all the others he worked on before.
Anyway, we managed to work somehow with this weird team. Unfortunately, we couldn’t hope at all to finish on time.
The first deployments
At some point we were ready with the first release of our product. We decided to make incremental deliveries to show our progress to the customer and to get their feedback as soon as possible in order to understand better the requirements because we didn’t have clear requirements during the whole life of the project.
What was my surprise when I realized that nobody in the customer’s office was using our product! The all boycotted it. Then we started asking questions and a whole new picture arose before us.
The ugly truth
Some time ago, in GigaLease there was a guy, about fifty, who was the chief accountant of the company and who was the only person who kept track of the client’s dues using some magic formulas in Excel spreadsheets. He used to present the reports to his management with no explanation where those figures came from and happily no one asked.
It happened that they hired a young lady on the position of Financial Director and she became a superior manager to the chief accountant. She wanted to know how the reports were generated but he refused. He was insulted of the fact that so young and inexperienced girl happened to be his boss and he boycotted her. Then she decided that their company needs a software product to do the calculations. The formulas will be publicly known and everybody will use that product. And finally, she will show her subordinates who is in command.
Then she came to our company with her 3-page request…
It turned out that there were political intrigues inside that company and they decided the most stupid thing – to solve them using a software program! And our management involved us into somebody else’s war not understanding that nobody wanted or cared about our product. The project was defined as “not important” in our camp and in customer’s. The project was just doomed.
Soon the project was canceled by the customer after nine months of hard work and a lot of problems.
Classic mistakes made
This is a summary of the classic mistakes (according to Steve McConnell) that I see in this part of the case study.
- Weak personnel (#2). Jannice’s assignment as a developer was a big mistake. We wasted too much time to understand that the development is not her strength.
- Uncontrolled problem employees (#3). Frank was really uncontrollable. The management had many conversations with him but he couldn’t change. I believe he just should have been fired.
- Friction between developers and customers (#7). This friction occurred because the customers couldn’t define their requirements during the whole life of the project. And the requirements were just undefinable since the company had very different problems and those problems couldn’t be solved with software.
- Lack of stakeholder buy-in (#10), Lack of user input (#11), Politics placed over substance (#12). All these mistakes relate to the customer and their political problems. I understand that this is difficult but our management should have understood earlier all those issues and should not have gotten us involved in this farce.
- Feature creep (#29). The requirements were so unclear and unstable so they were changing all the time.
In my opinion, the biggest mistake was the lack of ability to understand the customer’s problems and needs. We should have understood that their problems were organizational and we couldn’t help with a technical solution. There was no vision about what the product should do and this doomed it to fail.
Do you have such stories? I would highly appreciate your feedback.
The 3 Most Important Qualities of a Project Manager
Gina Lijoi of Interactive Project Management blog gives the 3 keys to project management success: finesse, time management and multitasking. I’ll put a brief comment on each of them (my 2 cents).
- Finesse. This stands for the ability to talk to people politely and convincingly. Sometimes this is the only “weapon” a project manager has to influence the customers, the managers or the team members.
- Time management. The essence of managing projects, especially software projects, is to complete them on time. I know many people who have problems with managing their times. A tip of advise from me: make notes and use software organizers. It’s human nature to forget. But if you are a project manager – it’s not forgivable.
- Multitasking. I would call it “ability to focus dynamically”. The project manager should be able to focus on a single task at a given time but should be able to switch to the other quickly and should never lose sight of “the big picture”.
Read her entire post here. It is worth it.
Classic Mistakes – GigaLease Case Study, Part 1
I was wondering for quite a long time how to organize my series of posts on classic mistakes and finally I decided to share some true stories from my professional experience as case studies and to discuss on the classic mistakes made there. Of course, all the names are changed – I don’t want to embarrass anyone, even those who made the biggest mistakes.
How it started
Some time ago I was working at a company called Mega Solutions. It was known as the biggest and the best software company in my country. They claimed that the company hired only the top experts in the area of the software development, used the newest technologies and charged the highest rates.
GigaLease was a small company which offered leasing solutions for industrial equipment and thus had serious customer base and pretty good income.
One day they decided that they needed a custom software product to track all the contracts they had signed, all the credits they had given and all the installments and interests due. So they turned to Mega Solutions to develop such system. They provided a three-page request and they wanted to have the software in four months. The Mega management agreed immediately and they signed a contract before any of the team members was available.
The first clash
I was hired a month later when only the PM was on board. He was a Business System Analyst also and I was the Team Lead and everything else since there was nobody else in the team. Being the only technical person in the team and a person with significant experience in building similar financial systems, the PM asked me to give him an estimate of all the project tasks to help him produce a reasonable project plan. My estimates were more than shocking – I predicted the project to take approximately 12 months if we had a team of 4 or 5 members, depending on their skills. In other words – about 50 man-months. Instead, we had a signed contract for 4 months and a promise from the management that I could have one junior developer added later to the team. It meant that their estimate was about 8 man-months. What a difference, ah!
Ed Yourdon in his famous book Death March
Looking for a solution
I and the PM (who agreed completely with my estimates) decided to ask the project sponsor for more staff and for new negotiations with the customer for more time and money since the actual contract conditions were impossible to meet. The answer from the customer about the money was very simple – GigaLease, although very profitable company, had a very small budget for IT solutions and we contracted all of their available money. They were more tolerant on the subject of the total duration and agreed to negotiate it if we reach some significant obstacles during the execution of the project. So, in fact we started the project without a clear idea how many people we would have and without a detailed project plan.
The “Death March”
My concerns about the project’s duration were based on the fact that the customer wasn’t sure what exactly they wanted. The time showed that I was right (as I will explain later). I had some experience with people who wanted to make a revolution in their business with a “small software program” (in their minds) ending with a product, which was a constantly changing and buggy mess of code.
So we shared our concerns with the project sponsor presenting him some simple calculations showing that the project would be a great loss for our company. He said: “Don’t worry! This project is not for profit. It is to make a strategic relationship with the customer and to use their services in the future at a lower cost.” Not only we were put in a “Ultra Death March” and we had to work day-and-night but we had no spark of motivation – there would be no reward, no recognition, no bonus.
This was my first project in the company. I was very flattered when they decided to hire me – it meant that I was one of the best developers in the country since they don’t hire average people. But now I realized that couldn’t prove my abilities – I was entitled “Team Lead” but I had no team and I had no chance to show my leadership skills; the product was decided to be a client-server system build with Visual Basic 6, which was considered already a fading technology, so I didn’t have the chance to improve my technical skills, too.
The classic mistakes made
In this part of the case study I can see the following classic mistakes (according to Steve McConnell):
- Undermined motivation (#1). Putting the team in a Death March project is a huge risk. Leaving them no straw to catch destroys the motivation totally and gives the project almost no chance for success.
- Lack of effective project sponsorship (#9). The project sponsor didn’t take our opinion in consideration. He never discussed the great possibility of failure with the customer on a management level. He didn’t approve (at the beginning) our requests for more people in the team so we could finish the project in shorter terms.
- Overly optimistic schedules (#14). The fact that contract was signed and the schedule was agreed upon without asking the team and without having some estimate was the major reason for the project’s failure.
- Feature creep (#29). Since the initial request was too general and there was no detailed specification before the contract, it was obvious that a lot of requirements will be revealed during the implementation phase and the feature creep was inevitable.
- Push me, pull me negotiation (#31). It happened several times when we negotiated more time with the customer. They agreed to give us more time and to delay a milestone but they insisted for some more features in exchange. As a result this made the schedule heavier and more difficult to fulfill.
The biggest mistake in my opinion was putting the team into a Death March project with no motivation. Our company created the “Marine Corps” mentality – if you cannot succeed then you are not suitable for our company. This kind of thinking could never bring a Death March project to success.
What’s next?
The next part of the case study shows how the team was built and how the customer reacted to our product. More classic mistakes!
Meanwhile, if you have some similar projects or similar classic mistakes, tell me about them in a comment, in an email, or in your blog. I believe that telling our stories we can help each other avoiding such mistakes and achieving our projects’ success.
-
Subscribe to this blog!
License
The content of this site is licensed under a Creative Commons Attribution- Noncommercial- No Derivative Works 2.5 Bulgaria License-
Admin
