#PM Flash Blog – What does project management mean to me ?

As part of #PMFlashblog, I am excited to share a pragmatic view of state of Project Management in the IT industry. This article is about “What does project management mean to me ?”

The tasks related to Project Management (PM) haven’t changed much since the last two decades. I have been in the industry since the last 17 years and seen both Agile and Waterfall era. I see that at a broader level most of the PMs effort is spent towards staffing projects, invoicing and reporting. However, a key observation has been that PMs are no more the center of attraction in Agile projects!

I am sure you would have heard about the Iron Triangle. Most of the projects I have across have some constraints of Scope, Resource or Schedule. Most of the time the Scope keeps increasing but the cost, budget and Schedule remain the same. During these situations, we agilists keep saying this is the wrong way of doing things and we need freedom, flexibility and sustainability. Guess what, this is when stakeholders and business people introduce Project Managers to “get things done”

For me, the Project Management is all about delivering what the customer wants in challenging environments. I have consciously tried avoiding the typical Agile terms like “Business value” or the “Customer value”. The reason being many a times the stakeholders or the business people themselves have tremendous constraints and demands from the investors that they ignore the real “value”. During these constraining situations, they want someone to “Get things done” rather than talk about “Values and Principles”.

Project management is all about “Getting things done” in complex and constrained environment, and whoever has the ability ends up becoming a project or a program manager. Since the PM work involves handling difficult stakeholders leading to a lot of stress,and this role is not for faint hearted. As the PMs need to be strong willed, and their focus is on “Get things done”, they end up becoming the bad cops all the time.

During the waterfall era, Project Managers were the final authority in deciding the fate of the project. Whether estimating projects, staffing or handling budgets. They always used to steal the thunder. With the popularity of Scrum, the center of gravity around projects has moved out of PMs. In Scrum projects, theoretically the PM tasks are split between the team and the Scrum Master, but the ground reality is, most of it is still managed by the Scrum Masters.

During early days of Agile, there were debates challenging the role of a PM in Agile projects, however, now it has become a reality that PMs are needed to handle the “admin” tasks. The prime reason being, they know how to “get things done” in any situation. Large companies implementing complex Agile projects still have dedicated project managers, but they don’t interfere much with day to day running of projects.

Here are the common things I have observed with all the project managers. I am sure if you visit this list and compare with your PMs, you might find most of them.

1. Experienced: They typically have a lot more industry experience as compared to rest of the team members

2. Delegators: They are very good at delegating the tasks to the team

3. C2 Style leadership: Command and control leadership style. It is very rare to see a PM who is like a servant leader.

4. They like meetings. At the drop of a hat, they schedule meetings and they have this uncanny ability to keep eyes open during post lunch meetings.

5. They are good at reporting. They can create very good power point templates, and spreadsheet reports. You just hand over them the data, and they know how to massage it before sharing it with their leaders.

6. Process neutral: Even though all the PMs still have a lot of affinity towards Waterfall brethren, they can adjust to any new process without losing waterfall thinking.

7. Crystal ball: All of them have some sort of crystal balls using which they get to hear all the gossips and rumors before you do.

Irrespective of whether PMs are the center of attraction or not, they know how to “get things done”.

#PMFlashBlog coming soon….

For the first time,  more than 70 bloggers across the globe are coming together to share their experiences around Project management.  The title of the blog is going to be “What does project management mean to me”

All the bloggers will publish their blogs on 25th Sept at 0100 Hrs GMT.  I am proud to be one of the bloggers as well.

As one could see from the following infographics, courtesy HennyPortman,  we have bloggers from Australia, Canada, Colombia, Denmark, France, Italy, Mexico, Poland, Portugal, Singapore, South Africa, Spain, UK and the USA 

 

Change the mindset of these 4 Practices

  Over a period of time,  Agile practices is taking its own shape unfortunately not for the better but for the worse.  Practices are given embraced forgetting the principles behind them. Especially over the key practices like  Retros, Daily stand up, Iteration planning meeting and estimation.  
What are those myths, misconceptions and what mistakes people are doing ?   These are covered in detail in the recently published  Techwell article.  The transcript of the article is shared below….
There are two popular mindsets team members have about retrospectives that I want to address: retrospectives are done only at the end of a sprint or a project and they are done to identify “what didn’t go so well.”
In reality, I have found that retrospectives support an “inspect-and-adapt” approach and are needed for continuous improvement. Agile teams are able to get together at any time and reflect on what’s going on in the project and how to work better. Having a “do-only-at-the-end” mindset dilutes the real intention behind retrospectives.
Read rest of this article here

Some of the recent stories on Techwell
------------------------------------------------------------

• Lessons to Learn from AOL's Recent Firing Debacle
• Why Radical Innovation Is Dependent on People—Not Process
• How Waste Impacts Software Delivery

Feel free to check out rest of my TECHWELL articles here

It works on my system !

I am sure many of us are familiar with this message “It works on my system”.   I recently got the same answer not from a developer but from the customer service team of the popular loyalty card.   As a card member, I couldn’t login to my account and reached out the customer care team through their Twitter help service.

There you go, I got the most popular answer  “we've been unable to replicate your problem here“.  

How do you deal with that response as a customer ?   What does that response reflect on their IT competitiveness ?   You report a defect to one of your developers and you hear this response back, how do you feel ?

A quiz on Self Organizing team

You come across a team which has the following characteristics

1. All the resources necessary (budget, time, people, tools, etc) to do their job. They can estimate and set the deadlines for their own delivery
2. No conflict at all in the team
3. Team feels very happy and relaxed all the time
4. They have no delivery commitments as they set their own delivery dates
5. Each team member assigns their own task

I know this is like a dream team. Do you think they are a self organizing team ?  If not, why not ?    Is there a test to check if a team is self organizing or not ? 

Photo courtesy:Mike Baird 

Net Promoter Scores - Do they work ?

    

Net Promoter Score (NPS) is as popular as engagement surveys.   There are several people who vouch for the benefits of  NPS. This is such a simple system that when I heard about NPS for the first time, I felt, this cannot be so simple !  There might be something I am missing.  The reality was, it is a simple system.   

The Ultimate Question 2.0 covers a great deal about the subject with tons of benefit. 

Interestingly we have few naysayers doubting the benefits of NPS as well.  Check this presentation out, where the authors seem to have data to prove the benefits of NPS wrong.

Another research paper here  has finding which says  “Contrary to Reichheld’s assertions, the results indicate that recommend intention alone will not suffice as a single predictor of customers’ future loyalty behavior. Use of a multiple indicator instead of a single predictor model performs better in predicting customer recommendations and retention.”

I hear that most successful companies like Apple, LEGO, Facebook, eBay, etc are using NPS.  I am sure there would be arguments – counter arguments on both sides for NPS. 

I am more inclined to believe the naysayers. We live in a complex world, and there could be multiple things impacting the loyalty, customer behavior, satisfaction etc.  It is not correct  to see a liner “Cause and effect” between the NPS score and the revenue generation(other benefits). This is like the Peltzman effect where “wearing a seatbelt induces people to drive less safely”  causing accidents, which goes totally against the linear “cause and effect” thinking.

Why do good people become bad bosses ?

I am sure all of us have come across  bad bosses at some point of time or the other.  But in reality, they are not really bad people at heart. The pressure and the stress pushes them to snap at people and ending up with “bad boss” title.   Here is a must watch video by the famous author  Annie McKee about this subject.

    A few take aways from this video
    1.  Bad bosses are good people under pressure

    2. People really like to change, unlike the popular assumption that people resist change

    3. People will change provided they are properly supported

    4. Don’t allow bad bosses to hurt your self esteem, dignity and confidence. Put your foot down to protect yourself

    5. Mindfulness is the key to success

Scattered meeting day syndrome

I have observed that the most un-productive day would be to have scattered meetings all throughout the day.  

For example:

• 9- 9.30 AM   First meeting
  10 – 12  Second meeting
  <Lunch break>
  2 – 2.30 another meeting
  3 – 4  last meeting of the day

After the first meeting, one would rush to get a cafe to prepare for the second one. By the time you grasp the second one, bell rings for lunch break. The day continues with meetings with a break of every half an hour, and end up with a pile of “real work” by 4 PM, causing too much stress. This leads to too many meeting syndrome. 

This is exactly what the Agilists dislike.In fact I have heard people calling Scrum has too many meetings !!   As per various researches, the task switching could cost nearly 40% productivity loss.

Solution

Personally I found that blocking a chunk of a day provides me the well deserved and dedicated focus.  Not sure if others have seen this happening ?   Have you experienced this ?  How do you deal with this scattered meeting syndrome  ?

Image courtesy : http://blog.officeformac.com/a-new-outlook-on-calendaring/

Can a process fix the broken trust ?

The last weekend, I approached concierge of our apartment complex to get permission to use the functional hall. The concierge pulled out a print out and asked me to sign it.  I have used the functional hall many times before and haven’t seen this new process of signing a form. 

The new form had things like  “The furniture if broken has to be replaced by the tenant”, “ Ensure to throw the trash in the bin”, “No smoking allowed in the functional hall”  and stuff like that. These rules makes sense but was curious why now ?   

I asked the concierge about the rationale of this process, and it seems the previous week some users of the functional hall created a bit of raucous. To avoid those issues in the future, they have brought this new process into place.

I had an aha moment when I heard this.  Is this not the same way our organizations and countries work by creating new rules and processes reacting to a problem ?    In the case of our apartment, Initially the body corporate  trusted the tenants and gave the freedom to use the functional hall but some where in between the trust was broken.  I am wondering now,  does this new process build the broken trust in any way ?   Does this process stop any such problems from happening again ?   Is this the right way to handle such issues or is there a better way ?