Everything I know about Project #Risk I learned from Brett #Favre #PMOT

** FILE ** Green Bay Packers quarterback Brett Favre looks to pass the ball after falling down during the second quarter of their NFL football game in Green Bay, Wis., in this Sept. 10, 2006 file photo. Brett Favre has decided to retire from the NFL after 17 seasons. FOX Sports first reported Tuesday March 4, 2008 that the Green Bay Packers quarterback informed the team in the last few days. (AP Photo/ Morry Gash, file)

God I loved watching Brett Favre play. Sometimes.

Other times he just frustrated the heck out of me. You really had to admire the man’s commitment and desire though. He was fully bought into the team’s success. He was going to do whatever he could to ensure the team won. Even more, I got the sense that he believed that the team would win. I got the sense that he was surprised each and every time he got to the end of the games and the score on the scoreboard went against the Packers. He had all the traits you absolutely love to have in an athlete. And he had all the traits and habits you hate to have in a Project Manager.

Project Risks

I don’t think I’ve been on a project where we have managed risks well. I don’t think I’ve seen a project where risks are managed well. Everyone understands what needs to be done but for whatever reason, the risk meetings aren’t followed up on after that first risk workshop. I started to wonder again why that would be. Everyone understood the reasons behind the risk workshops and even on projects that weren’t overly busy we didn’t seem to go back and revisit risks. We even created new risk deliverables. We had risk heat maps and risk radars! And then we created them once and never really went back to review them or recreate them.

So the question is why? Why are we so bad at following up on something that most people agree is very valuable?

Just like Brett Favre, we just didn’t feel there was a lot of risk.

Be the Ball

Good project teams ‘become the project’ at some point later in the project schedule. I don’t mean they physically become the project, but they become vested the project’s vision and success. Project team member’s want the project to succeed and want the clients to realize the benefits. In this way team members become the project and lose some of their objectivity. When project team members become the project they first thing that happens is that they believe in the project, the second thing that happens is that they believe in each other. Eventually this can result in decreased formality, diminished reporting of issues and risks as the team doesn’t want to be adversarial and also they believe the issues will sort themselves out. In this way, as your project team gets stronger and becomes the project, they lose their objectivity.

Annnnnnnd before you know it you are chucking up a 70 yard bomb with 2:00 to go instead of just running out the clock.

More and more companies are now resourcing external Project Managers that are only on board for a short period of time. I believe this is trying to address the issues that can be caused by Project Managers becoming too comfortable in the client environment. Similar to the project team, this familiarity can cause issues to not be raised and decreased formality as the project managers believe more in their team mates and the clients.

Question

So the question remains. How can we reap the benefits from increased relationships to the Project Manager without losing objectivity? One way to attempt this is to use consultant Project Managers and only have them to a short period of time. I’m not sure if this is optimal though as new Project Managers have to learn the business domain and organization and just when they are up to speed they need to be swapped out. With every new Project Manager there is ramp up and learning time and with every departing Project Manager we lose valuable project and client knowledge.

Active Project Assurance

What we are implementing is a concept that has been around for a while – Project Assurance. Lately Project Assurance has taken on the form of Project Checkpoints were we get together and sing around the campfire. I jest but the weekly conference call checkpoints without everyone having the knowledge or the context of the project are not very useful.

Usually the call goes like this:

You: Got any issues?

Me: Nope.

You: OK, talk to you next week

What we are proposing here is quite different.

Active Project Assurance involves a third-party facilitating ongoing sessions with the project team to provide that objectivity while encouraging the Project Manager to continue to build relationship with the project team and clients. In our case the Project Management Office participates in the Project Initiation activities and then facilitates the Project Retrospectives and Project Risk workshops. We can then provide Project Assurance to objectively review the project while still allowing the Project Team to be the project. Without the enhanced project team and client relationships, the Project Management Office does not have biases for issues and risks. Both of those still scare the heck out of the PMO.

This allows the Project Management Office to have enough context to actually consult on the project and also allows the project teams to become more informal and build relationships that ultimately benefit the project.

And maybe we can stop the odd pick-6 while we are at it.

Advertisement

#Three Deadly Sins of Software Development #agile #hubris

hubris

In my experience, I have encountered three deadly sins in Software Development. Project teams can overcome almost any problems if they don’t fall victim to these three deadly sins. Unfortunately we seem to have progressed through these deadly sins throughout the years as we get more and more experienced in Software Development.

Technology-Centric

Our first deadly sin was the sin of being technology-centric. The first aspect of this was the behaviour in the 1970’s where Information Technology professionals had a belief that they knew what was best for clients and would essentially decide for the clients as to the specific type of functionality delivered. I can remember early on when we still gathered requirements from the users, but we sought no validation on the design or interface. We as professionals know best in regards to how those components should be designed. Even our terminology set the stage for the principle that the business was not informed enough to make decisions on their own. They were only ‘users’ after all. Information Technology professionals would create the system and the business could simply ‘use’ the system we created. Nothing more.

The second aspect of being technology-centric came after we begrudgingly accepted that the business were more than just users and should validate the system design and interfaces. OK, we will let you control that aspect, but Information Technology Professionals will control the selection of all the technology and patterns that lie beneath the interfaces. All of those technology choices must remain with the Information Technology professionals and it would be beyond business users to provide input on technology and patterns selected. Information Technology Professionals will decide on all architecture without collaboration.

Thankfully we now understand that if a technology or architecture is truly better, that should result in more value for the client early and often.

Methodology-Centric

Shortly after being technology-centric, we flowed right into the methodology-centric phase. Alright Mr Client, you define the requirements and value that the project will deliver, but we will define exactly how we will deliver the project. This started out by defining a very specific process for the Waterfall Software Development Methodology, but has evolved throughout the years to be equally specific and constraining processes for hybrid and Agile Methodologies.

In short, any methodology that a project follows without customization for a client, project team, or project is flawed. I’ve always thought how curious it was that Agile proponents once freed of the shackles of Waterfall were so eager to put Agile shackles on every project they saw.

Topology-Centric

And the final deadly sin is one that is a bit recent to the dance, topology-centric. I use topology-centric to refer to the desire by Information Technology project teams to be embedded at a very senior, strategic level for the project. Many times the Information Technology solution can be made better if Information Technology Professionals can work together on the business problem and not just the solution. It is ironic that early on Informational Technology was trying to limit the access the business had to Information Technology components of the project and now the business is in charge to limiting the access Information technology has to the business components of the project.

The more things change, the more they stay the same.

To be clear, the deadly sin is not to that Information Technology is denied access, but rather that Information Technology demands that they should be granted access by default.

Summary

Information Technology Professionals have to remind ourselves we are a service and need to embrace the servant leadership in all aspects of project delivery.  We as Technology Professionals only encounter these deadly sins when we think we know better than the clients. If we avoid these types of Information Technology Hubris, our projects have a much better chance of success.

Turn the Ship Around by @DavidMarquet Book Review #agile #pmot

“Turn the ship around” by David Marquet is a rare gem of a book. It is one of those books that come around once a decade. The book is very well written, provides a lot of lessons that you can apply to your situation, and is very entertaining to boot. In his story of how David Marquet turns around the Sante Fe, we can see similarities to companies, jobs, and teams in our own situations.

It is an inspiring story how one can turn the leader-follower model and turn it into the leader-leader model, even in one of the most seemingly hierarchical situations in the world, the military. I’ve read multiple books now that dispel that myth. I think the military probably gets a bad reputation of being hierarchical, but to survive has probably adapted more and quicker than perhaps any other industry.

Mistake Monitoring

There are many things that you can take away from David Marquet’s book based on what you are experiencing and what problems are foremost in your mind. For me, I was thinking about the challenge of making project reporting more lean and valuable.

So when I read the section lamenting that monitoring in the Navy was just focused on preventing errors and mistakes but not at getting better or more efficient, I immediately saw  parallels with project reporting. I was thinking the same thing about our project reporting. We report about whether the project is yellow or red and what problems we have encountered, but we rarely if ever discuss how we became more efficient or got better on the project. If we are lucky, we discuss those items in the project or iteration close outs. Many times, the items are small improvements and many times they don’t get shared outside of the project team.

It got me thinking, how can we monitor and focus on efficiency improvements on our projects? As Marquet mentioned, the bar is set quite low if success is measured by the absence of errors and mistakes. If success is just based on meeting budget and schedule, are we really trying to improve and get better?  Why wouldn’t team members just provide large estimates so that they were deemed a success. Where is the focus on continuous improvements and wanting to get better? I want to do more on my projects than just avoiding mistakes.

I don’t have answer for where this will lead and what we are going to monitor and share. But thanks to David Marquet we are asking the question to our teams and trying to determine how we can set the bar higher and get better and more efficient on our projects. Maybe that is a good place to start, to say finishing a project on time and on budget is not enough and to ask the stakeholders what other goals and objectives should this project have? And then overall, what goals and objectives should the Project Management Office have?

I’ll report back in a future blog on what we have tried and what have worked.

Project Manager’s #1 Challenge #PMOT

risk-vs-reward1-e1330209788902

One thing that has always perplexed me on projects is how poorly we as Project Managers and project teams manage risk. All of us have the initial Risk Management meeting and try to capture the risks and mitigations required. But even in that first meeting, we fall short in identifying and planning how we are going to address the risks on the project.

Why?

At one time I had thought it was just because we as Project Managers got busy with the work on managing the project and forgot about scheduling follow-up Risk sessions. But that wasn’t it, even when the Risk items were incorporated into weekly status reporting, the effort and attention paid to risk management was just ceremonial. There was something else at play.

I was working on another long project and we were discussing the challenges with the issues and risks encountered. In a retrospective we discussed how we managed the issues and risks looser and looser as the project executed. We did this as we became more comfortable with the client and they became more comfortable with us. Unfortunately new players came onto the project later and changed characteristics of the project. This changed the issues and risks but we were not managing them as formally as before as we became comfortable with the issues, risks, client, and the project.

One person summed this situation up perfectly. “On projects it is natural for the project team to become the project. This eventually happens with the Project Manager.”

This is where the lack of formality and process can be a problem for the Project Manager and the project.

Become the Project

“Become the Project” – sounds rather Zen-like doesn’t it?

Become the Project to me means that you have somewhat lost your objectivity and like the rest of the team you are thinking in a positive and trusting manner. You start to expect issues to be resolved very soon, that risks will not happen, and that if things happen we will address them as one homogeneous team. Well it turns out that perspective is valuable and required by some of the team members as they are working through deliverables, the Project Management and leadership need to be careful to not fall into this lack of formality.

So what to do?

What can we do? As much as we say not to do it, it is human nature. Trust will be built up and used after working with the same people for months and years.

This is where your Project Management Office or Deliver Management Team needs to help your project team by providing the independent 3rd party or sober second thought perspective. The Project Management Office or Delivery Management Team’s role is not to own the risks and issues but to facilitate the review and consult on them as an independent 3rd party. In this way, we ensure the review happens and we make decisions based on all the most current data from the project balanced with objectivity and experience.

Ultimately you want your team and Project Manager to be the project, we just need to add a check and balance to ensure issues and risks aren’t overlooked.

Would you like fries with your McApplication? #NoEstimates

There is a great difference between a fine meal and McMeal. The fine meal typically has been crafted with years of experience and training by chefs around the world. The McMeal is put together with years of experience based on what people want at 1:30 am in a drive-thru. The fine meal also places forethought as to how the components work together and play off of each other. With McMeals and other fast food meals, you are left to your own devices as to what you would like combine together at the last possibly moment.

Software Development

Similarly, Software Development can create solutions on which great experience and effort is expended determining how the components fit together or we can slap the functionality together for a McApplication. Agile can and has been guilty of creating too many McApplications over the years.

User Story Mapping

User Story Mapping is a great tool, but unless it is followed up by some analysis and design work to architect the solution, we are just visually drawing the new McApplication. While the concepts of delivering in iterations and visually planning the iterations is extremely valuable, jumping into delivering without architecting the overall solution is misguided and sub-optimizing.

If your first project work is cutting code after you have created a User Story Map, you are well on your way to creating the next McApplication.

We always need to remember we are professionals committed to creating, designing, and delivering the best solution to a business problem, Sometimes this may involve providing counsel to clients on why some stories should not be done, why some stories should be done later, why some stories need to be done now, and why some stories that they haven’t thought of need to be added.

Client priority rules the day of course, but if we just do what the client identifies without providing our expertise, we are no longer professionals. We are just order takers.

To avoid being just order takers we usually need to do some detailed analysis on what a story means and how it needs to be implemented. Just capturing the highest ‘placeholders’ to discuss functionality means you are creating your architecture as you go along. Yipes.

NoEstimates

Which brings us to #NoEstimates.

No Estimates does not focus on creating a better solution. No Estimates has been created so that the project can be forecasted. It proposes nothing to help create a better solution to a problem. Even worse, when No Estimates is followed to the letter, it can even absolve the team of project leadership duties.

No Estimates proposes that we will just work on what the client wants, when the clients wants it and we will stop when the client wants to. It overlooks a key responsibility of project teams to save the client from themselves with our experience and expertise. Agile sometimes seem to shy away from tough discussions that should happen early on projects. Some projects should never start.

Agile proponents forget that not only should code to tested early and often, but incorrect client concepts should also be. If we are taking direction on a client priority that we know is wrong and will result in a lesser solution, and we haven’t done everything we can to change their mind, then we are not Agile.

No Estimates proponents will probably state that all those things should be done on a project in addition to No Estimates, but by not putting design and architecture front and centre it is clear they primarily value forecasting.

Due to this, the type of solution you will get out of a No Estimates projects will probably be a McApplication rather than a fine meal and you’ll probably be hungry for a new solution before long.

Solution Leadership and healthy adversarial discussions over difference in opinions is not valued highly on No Estimates projects. The focus is on  forecasting and doing whatever the client want to do next….

Would you like Fries with that?

 

 

 

What a Project Manager does #PMOT

I often get questioned by my kids on what exactly I do in my job. I tell my kids that I am a Project Manager and I work on teams that create web sites but that still seems to not convey ‘what’ exactly I do on a daily basis. Then last weekend I had an experience that I was able to point at to show my kids what I do at work. So what was that experience?

Building one of those metal storage sheds.

Construction

Turns out it was my wife’s idea to get a metal shed. We needed to get it to store bikes and softball gear in it. I’m usually the person to put these types of items together but this time we had a lot of things going on during the weekend so my wife got our two nephews to help. Things were going well and the floor got put together well. The shed started to take shape with the walls and frame being put together. The top frame went into place as did the middle frame that re-inforced all of the walls.

Looking back this probably was the early part of development projects where everything is going swimmingly as components haven’t been integrated and tested yet. But very soon, we were going to experience our first integration test.

Testing, Testing, 1-2-3

I hardly provided any assistance during the development, like a good Project Manager. Just let the team go. But then I was starting to hear some frustrated tones from the back yard. The last panel on the back yard wasn’t lining-up. No matter what they did, the screw holes were a centimetre apart.

They finally came in complaining about the stupid shed kit and I came out to see if I could help. I walked around and looked at the instructions and asked them to describe how they put it together and how they had tried to fix it. I checked the schematics and then they noticed that in one corner the two pieces were not flush against each other like the other three corners.

We then tried to line up the panels but the screw holes were still half a centimetre apart. sigh.

Back to the drawing board.

We then walked around the shed inside and out looking for something else that was out of line. By now we had the experience that one corner or side was probably larger than another. My nephews got the idea to measure all of the sides and sure enough one of the braces was too long. We shortened the brace and the screw hole lined up perfectly.

Summary

Over dinner that night I said to my kids that what I did on the shed was exactly what I do at work. I help project teams plan, but most importantly I help them resolve issues. Most of the time they resolve the issues themselves, I just facilitate the process.

I’m not even gonna talk about how hard the roof was to get on….

Doctor’s Notes and a broken system

We recently had a news items here is Manitoba where an NDP member of the Legislature introduced a private members bill to remove the stipulation to require a Doctor’s note until you have been away for greater than 6 days. Seemed to me like a totally reasonable request. It also occurred to me how broken the system must be if someone thought getting a Doctor’s note was a good solution initially.

It appears that the Doctor’s notes were required to try to address unwarranted absenteeism. The problem with this policy is twofold:

  1. By forcing potentially sick employees outside and into a Doctor’s office you are potentially increasing the severity of their sickness and increasing the chance they will infect others.
  2. If they are unable to acquire a sick note because they lack a family doctor or have had too many sick notes, they will probably come to work and make more people sick. This in turn will result in point number 1. 🙂

Ultimately at the end of the day, you will need to trust your employees. If they are not engaged they possibly could take unwarranted sick days that could impact the business. But you know what? That impact would be minor to the impact to the business when they ARE at worked and not engaged. They could waste more time than during their unwarranted sick days. (especially when you factor in other employees they are also distracting)

When you are thinking about designing solutions to the problems, ensure you are treating the problem and not just the symptom. In this case, playing hooky is not the problem. It is just a symptom of being not engaged and not feeling valued.

BTW, increasing the procedure to only require notes over 6 days isn’t fixing things either. Spend the effort to talk to people and understand what they would like to do at work. What makes them feel like they aren’t working? What gives them a sense of satisfaction? What makes the day fly by for them?

How would they recommend getting employees more engaged?

You might be surprised at the answers you get. At the very least, just asking the question increases their engagement and probably starts the process to reducing absenteeism.

Brooks Laich #Leadership and #Winning

Brooks Laich can be on my teams anytime. In one of the cruelest turns of fate, Brooks Laich was traded from the Washington Capitals to Toronto Maple Leafs on February 28th. If he wasn’t traded, he would have been demoted to the Washington Capital’s American Hockey League team to try to get some salary cap relief. One way or another, Brooks Laich was not going to be able to compete for a Stanley Cup for the team that he lived and bled for over the last 12 years.

And then Brooks Laich who had been a Washington Capital since 2004 was suddenly gone.

My Brooks Laich story – March 22nd, 2013

I was lucky enough to sit beside Brooks Laich’s relatives at a Winnipeg Jets game three years ago. They had made the trip out from Saskatchewan to see Brooks play. Two adults and two kids were there all decked out in Brooks Laich jerseys and there were the most friendly, honest, and polite people I have ever sat beside.

They made such a good impression I couldn’t help but clap when Brooks Laich opened the scoring at 12:10 of the first. Ever since then I have honestly cheered for the guy.

February 29th, 2016

So Brooks Laich was looking like he would finally get a chance to complete for the Stanley Cup after 12 years and then he wakes up in Toronto a day later. I thought he would be crushed and I am sure that he was. No one could ever tell from how he carried himself though.

All I heard from him in his first media interview was how happy he was to join the Maple Leafs and about the great young core they have in Toronto.

I don’t need to see Brooks Laich name on the Stanley Cup. I already know he is a winner.

Code Monkey Club #KidsCoding

monkey

Code Monkey Club

Well I am back for my second year of holding lunch session with kids at River West Park teaching coding. I learned quite a bit from my first year and I’ve changed the offering a little bit. In my first year. I created the exercises in MineCraft. This was both good and bad. Good as it immediately got kids engaged with the exercises, but bad because the kids were more focused on doing things in the game instead of learning about coding. I got a lot of feedback that the kids loved the sessions but the kids then wanted to learn how to build entire worlds in MineCraft and create videos on YouTube. Clearly, I needed to think about this a little differently.

Code.org

The white knight for me were the excellent resources that are available for everyone on code.org. The exercises illustrate programming concepts and fundamentals and are available for everyone to use. They leverage existing games/themes like Flappy Bird, Star Wars, and MineCraft.

The best part is the interface that code.org has where the kids can drag and drop logic blocks and then see the results in playing the game immediately. The interface is ideal for getting kids excited and receiving positive feedback on their work. Even better, my kid’s school had already done some of the basic exercises so they knew the interface.

If you are interested, you can find the exercises at the following link

What I add

I’ve just had one session,  but so far the content allows for the kids to learn more and be more engaged! I get to spend less time managing/troubleshooting exercises and more time assisting the kids with the exercises. Since the kids have already taken some of the basic exercises, I am also able to focus on the exercises that reinforce/introduce more advanced programming fundamentals. This allows me to add insight and details on what is really happening behind the scenes with the program.

So I think this is a great set of exercises, but we will see as we work through them. But so far, they are engaging the kids more, teaching them new concepts, and allowing me to add detail and insight were appropriate.

And I think we are still having fun!

 

Does #Google hate #Agile

I came across this post about how Google thinks Agile development is nonsense by Michael Church. You can check out the article here.

Where to start?

Ok, lets start at the beginning. It appears Michael Church has made the leap that Agile is Scrum and Scrum is Agile. That is quite the leap and one that I disagree with. I myself have had a couple of posts on why I don’t believe Scrum to be an optimal method. Of course, I would never say Scrum is nonsense.

What else?

“It’s a culture of terminal juniority. Product development and architecture aren’t the programmer’s job, because they take longer than two weeks. Rather, the programmer works on atomized feature-level “user stories”. This is OK for a junior who’s learning the codebase and software engineering principles and may appreciate the guidance, but anyone with more than 5 years of experience is going to find it to be a dissatisfying way to work. There is no place for an actual senior engineer on a Scrum team.”

I would say that Michael has never been on a well-run Agile team and doesn’t understand User Stories. User Stories are designed to include Architecture issues and deliverables. Certain frameworks like Disciplined Agile Delivery actually formalize this role as well. The two-week limit doesn’t need to be adhered to like a commandment. Some exceptions should be made. For someone who has worked at Google like Michael, his lack of Innovation seems to be adhered to solely for the sake of the article. If the Scrum process doesn’t fit, change it. I find it hard to believe Google doesn’t innovate like this elsewhere.

“It’s aggressively short-term, by design. These methodologies are designed for scrappy, unproven consulting firms that need to bear down and pass their first high-profile project. In that context, they probably work– at the expense of technical debt and tired workers.”

Not sure where Michael gets this opinion. If anything, Agile is the one framework that is focused on sustainable pace and ensuring that technical debt doesn’t get built up and people don’t work excessively. User Stories are not just for user functionality, technical debt gets added there as well to ensure it is addressed as part of the sustainable process.

“It has no regard for the programmers’ career needs or desires. See the points above about Agile’s short-term orientation. Now, people are willing to give up their career goals to pitch in on a short-term crisis, for two reasons. First, if it’s genuinely important to the firm, then it does help their career to do so. Second, a story of having solved a genuine crisis under time pressure can be a career booster. Saying, “I was in the War Room and had 20 minutes each day with the CEO” means that you were important and valued. Saying “I was on a Scrum team” means “Kick me”

Wow. Again Agile is the one movement that talks about respecting people and having people choose what they work on and where their career is going. The concept that Agile is only for short-term crisis mode is a falsehood that Michael can’t seem to let go. And trust me, just being in the same room as a CEO doesn’t mean you were important. It sometimes means he doesn’t trust you.

“It’s micromanagement. User stories and backlog grooming are there to control what the engineer works on. The absurdly frequent meetings (and so many different kinds of status meetings!) are to intimidate him into not slacking. The story points are there to track productivity (in some superficial, inaccurate way). The talk of “removing impediments” is code for “spotting slackers”. Even for people who have nothing to hide– even for people who’d be strong performers in a more sane, relaxed, progress-over-rapidity organization– a surveillance state is an anxiety state. It sucks, and if you’re good at what you do, it’s insulting to have to justify days and sometimes even hours of your time, and to be jerked around if these estimates are even slightly displeasing to the “product owner”

Absurd. Again the developers pick what they work on so there is more control that someone assigning tasks in a traditional project. Michael, I think thou dost protest too much. 😉

“At identifying low performers, it has an unacceptably high false-positive rate. Let’s not kid ourselves. The reason “Agile” is so popular is that it carries this mythology of spotting low performers immediately– in two weeks instead of over months– and giving objective cause to fire them. (Agile/Scrum is, in essence, a permanent PIP.) I’ve heard it put this way: “use Scrum to spot your Scum.”

OK, I think we will leave it there as subsequent points are along the same line. I have never heard of anyone promoting Agile as a means to spot low performers.

I’m not sure what the motivation is for Michael writing this article, but I do know three things:

  1. Agile is not Scrum
  2. Michael has not been on an Agile team and would benefit from that context before writing on something he does not know about. Me writing on how Google teams are organized similar the Lord of the Rings Fellowship would be equally as uninformed and wrong.
  3. The article reads almost like a ‘shot across the bow’ of Agile being used at Google. A warning to not use it or bad things will happen with developers leaving. A good dose of Fear, Uncertainty, and Doubt.

Hate to break it to you Michael, but with Google promoting code thousands of time a day, you are already very Agile! I recommend reading about other Agile methods and suggest changing Agile methods to suit your needs. I know Google has the ability and track record.

BTW, the client engagement and customer focus of Agile may just have avoided that whole Google+ thing…

Just Sayin’