The Hard-Nosed Project Manager

Agile estimation error

This is basically the comtent of a comment I made in response to the Cost (and Schedule) Estimating Foundations post by Glen B. Alleman in his blog.  As usual, it is spot on.

I have now seen a couple of Agile projects unfold and one of the challenges they face is the accurate estimation of story points (SP).

On a project that has hit its stride, with no particular challenges, I witnessed the number of SPs achieved on two consecutive sprints fall to half the estimated SP/sprint and then to one tenth estimated SP/sprint.  Of course the effort and budget expended did not go down at all.

Either the development team suddenly went stupid (unlikely) or the failed to assign the right amount of SPs to the tasks.  There are many ways this second scenario unfolds, but the most likely is that the team got a bit full of itself and estimated down the effort required.  A fixed amount of people can produce only a set amount of work (SP) per amount of time (sprint) hence the weird results. 

Apparently the so-called iron triangle applies to Agile too.

What do you think? As always questions and comments are welcome.

Connect with me on LinkedIn. I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.

Odd LinkedIn questions about Project Management

I was reading through my LinkedIn group discussions this morning and I happened on a
couple of very odd questions:

• Hi, I have just started a new role as Project Manager, although I have my Prince2 quals, I am new to Project Manager...what good starting advice can you give to me to be a great      Project Manager?
• When managing a project you have no adequate experience of; What are your DOs & DONTs... to ensure success is achieved within a reasonable time frame?

Since I’m a mean old PM, I don’t get scared and that is why I call these questions “odd” instead of freaking scary.

Both these questions come from Project Management groups. The first one is from a person with some PRINCE2 (Projects IN Controlled Environments) credentials.  One would think that a PRINCE2 certification at any level would give you some idea of the basics.  I refrained from pointing either of these posters to Project Management for Dummies because that would be mean to someone that needs a lot of help.

My main problem is with whoever is contemplating putting these two in the line of fire on a real project.  Project Manager is a leadership role; sure you do management but more importantly you lead people.  When I was a soldier, we were given leadership training prior to leading people.  Those that could not lead were just no placed in leadership roles  and no one (short of a shooting war) was expected to pick up the skills on the job.

What do you think? As always questions and comments are welcome.

Connect with me on LinkedIn. I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.

 

 

Why you need governance

If you don't follow Glen B. Alleman's blog, you should.  You wonder why you need governance?  Look up this post.

Connect with me on LinkedIn. I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.

Lean Startup in the Enterprise webinar

I just listened to the recording of the PMI Agile CoP webinar called Lean Startup in the Enterprise.  Points the presenter made:

• Webinar is based off field experience.
• Discussed Lean Startup as a scientific approach to startups.  That can be extended to product development.
• The loop Ideas – Build – Product – Measure – Data – Learn should actually start at the Learn      step.  Otherwise what do you know about the problem you are trying to solve?
• The typical comment about waterfall being good when you know the problem and the solution while Agile works with a known problem but unknown solution and Lean Startup works with unknown problem and solution.  My experience is that the problem is never known anyway.
• Mentioned the Cynefin model and stated that there is a leadership shortage in situations where the problem and solution are unknown.
• Companies are setup to execute not solve problems.  That is true in my opinion; most companies repeat the same thing over and over.
• The distinction between Project and Product Thinking is important. I’m not so sure; when my projects conclude, there is a product or service or transformation that is delivered.  It sounds to me like a vocabulary thing.
• Makes the valuable point that projects are not done deals but rather experiments.  A schedule is not a holy book and does not predict the future.
• Requirements are hypotheses.  Yeah; it always has been the case.
• Discussed various contexts B2B, B2C, internal, etc.  Everyone claims that they are special, that their needs are unique, etc.  I heard that before and found it to be false; the planets orbit the sun for everyone.
  • Discussed a number of ways to find out if you have something worth developing.  Customer interviews, fake doors (let’s say a website that is just a front), concierge (fake automation), etc.
  • Theere are also a number of ways of deciding needed feature. Feature fakes, A/B tests, relabeling
  • Aware, Hopeful, Satisfied, Passionate…  I actually live through this right now; I have this new, amazing product that does not sell because clients don’t know about it.
  • Internal customers need to want the product.  If the use is mandated you are in trouble.
  • Process improvement vs what I call a pathological process. Something that evolved through time to fix a zillion issues and that is now Frankenstein.  I encountered that may times in big corporations. Cleaning up used to be called process re-engineering
• Requirement validation through experimentation.  A little at a time and on a continuous basis.

I liked the webinar. I’m not all in but I’ve seen so many clients that ask for the whole enchilada but actually use only some specific features.  Why develop the rest at a high cost?  A few perfect features are better that a whole bunch of junk.

What do you think? As always questions and comments are welcome.

Connect with me on LinkedIn. I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.

Accelerated Change Management for Business Transformation™ … toward Agile & Open Organizational Models webinar

I just listened to the recording of the PMI Aerospace and Defense CoP webinar called Accelerated Change Management for Business Transformation™ … toward Agile & OpenOrganizational Models.

Please don’t make the same mistake:

• The title has Agile in it and, while I am no great fan of Agile, nothing Agile about the webinar.
• Basically it is a 1 hour long mish mash of disjointed ideas by two gentlemen that are not with the times at all.
• Terrible slides, every single one a busy and antiquated and eye chart.

I typically catch webinars at lunch time.  This one I took in after supper so I managed not to spoil my meal.

What do you think? As always questions and comments are welcome.

Connect with me on LinkedIn. I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.

Why Employers Aren't Filling Their Open Jobs

I typically don’t read HBR material because over the years I found HBR to be too academic (not representative of reality) this is however an interesting blog post.

Reading between the lines you can infer a few practices that are not good for companies
in the long term:

• Trying to low ball potential employees.  That works only until their skills are in such demand that they walk out.  People may take a position out of necessity but it is the rare person who likes being taken advantage of. 
• Extending the hiring process.  That works only until their skills are in such demand that they find a position somewhere else before the company makes up its mind.

Many North American companies are relying on IP to survive and hopefully thrive.  IP is created among other things through top employees and collaborators.  Current hiring practices may well go against acquiring those top employees and collaborators.

What do you think? As always questions and comments are welcome.

Connect with me on LinkedIn. I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.

The Illusion and Promise of Self-Organizing Teams webinar

I just listened to the PMI IS CoP webinar called The Illusion and Promise of Self-Organizing Teams. Points the presenter made:

• What we have is a spectrum with on one end the manager-lead team and at the other end the self-governed team (no manager).  The self-organizing team lies in the middle.
• Pitfalls:
  • Lack of management support at every level
  • Avoidance of team responsibility.  Responsibility has to be part of the package.
  • Death of empowerment.  If they self-organize they have to have the power (and the responsibility that comes with it)
  • Distrust.  I think this is a pitfall in every environment self-organizing, self-governed or manager-lead
  • Disrespect.  Goes hand in hand with distrust; you don’t trust people you don’t respect.
  • Not nurturing collaboration.  Otherwise it is not a team.
  • Impatience with continuous processes.  Things do not appear fully formed, they evolve.
  • Not cultivating a culture of learning.  Again, you have to evolve.
  • Lack of purpose and vision.  People have to know why they are doing something.  Money, passing time, etc., are not good reasons
• Pros:
  • Create a compelling purpose and vision.  Set the goal in a way that everybody is on board; what does this project solve, who/what benefits from the project.
  • Nourish passion.  The purpose and the vision is a team activity (otherwise it is manager-led, no?). Spoke about the 5-why technique (Ideo started this I believe) as a way to drill down on purpose and vision.
  • Define project success.  Some think this means a project that ends on time and on budget; that is simplistic.  For example, a project ends on time and on budget but delivers an outcome that does not benefit anyone.
  • Develop cross-functional teams.  Broadens the horizons; it works  but it can’t be maintained, most people give up before reaching the end of a purchase (for example)
  • Empower.  I personally hate the term but I take it as remove the road block a command and control approach can create.  A leader doesn’t need to take EVERY decision and probably isn’t the best person to take EVERY decision.
  • Get the team to accept the responsibility and accountability.  Help members along because leadership starts with individual leadership.
  • Acknowledge contributions, results, and performance.  I reversed the speaker’s order because sometimes the flow of the project may mean that a contribution ends up on the cutting room’s floor.  Celebrating results and performance are strong motivators

Pretty good webinar that speak about a number of reason why Agile teams sometimes are Agile just in name and how to walk the walk.  I love that the speaker did not picture Agile and self-organizing teams as panaceas but rather an alternative that can work you if you really try.

What do you think? As always questions and comments are welcome.

Connect with me on LinkedIn. I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.

 

PMI IS CoP webinar; 06/03 at 12h00 Eastern - The Illusion and Promise of Self-Organizing Teams

PMI IS CoP webinar; 06/03 at 12h00 Eastern - The Illusion and Promise of Self-Organizing Teams

There will be a PMI IS CoP webinar titled “The Illusion and Promise of Self-Organizing Teams “ on 06/03 at 12h00 Eastern. Those who can’t attend should look for my comments after the webinar.

Show up in the office or else…

Marissa Meyer (Yahoo) has told telecommuters that they now have to work from an office.  That is a blanket order that demonstrate a significant lack of leadership.

Looking at this in black and white I'd say that under performers, out of alignment employees (call them what you want) should get a meeting with their manager and be told that it's office work or ship out. Maybe throw in a 1 month grace period if you feel kind.  Those that perform should be left alone.

A leader should not apply the same rule to everyone; be extra kind to good people and ruthless with underperformers.

What do you think? As always questions and comments are welcome.

Connect with me on LinkedIn. I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.

If everything is going fine, why don’t you show progress?

The other day I read a quote on Glen Alleman’s blog.  Funny (not really) but I had such a discussion this morning. 

Last December we engaged into discussions with the supplier and when it became clear that they did not understand our needs, we asked for a meeting.  With the holidays coming, the meeting was set
for late January.

The meeting took place, we reiterated our needs, and then the supplier was to respond via his documentation of requirements and of a supporting system architecture.  I asked again and again but no documents were delivered.

This morning, some guys were unexpectedly in the meeting.  When pressed, they stated that they were "working on it", that they could not give a date, and that we should document perceived road blocks while they are “working on it”.

They are an Agile shop but when you offer your insight on the problem,accepting input from clients is very Agile, they demured.

Fish don’t make noise and they don’t walk but this looks like a (rotten) fish…

What do you think? As always questions and comments are welcome.

Connect with me on LinkedIn. I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.