Teaching Project Management to Juvenile Felons

Today I was able to present Project Management as a career at the Alfred D Noyes Center’s annual Career day. I volunteered out of a spirit of service and a firm belief that project management skills can be applied to real life. The Alfred D. Noyes Center is a juvenile detention center. I didn’t realize this when I signed up – I sort of thought it was a center for at-risk youth. No indeed, it’s a center for already-done-the-risk youth, kids who have committed felony’s including rape and murder.

I had four groups of kids, two sets of boys and two sets of girls for about 1/2 hour each. I prepped my presentation using materials on Careers in Project Management and Project Management for Life from the PMI Education Foundation. So I didn’t have to create any slides, rather, I whittled the slides down to the basics and what I thought the kids could easily grasp;ie what is a project, what do project managers do, what are stakeholders. I also focused on the earnings potential in project management and my message to the kids was:

Principal Britton and me

Principal Britton and me

You already have basic project management skills

That proved to be a good message that kept the kids engaged and interested in Project Management

My first group of boys ranged from about 14-18. I started off describing earnings potential and then got into a project analogy I knew they could grasp: football. I borrowed from Any Given Sunday. “Football is a game of inches.” Then I got them thinking about when preparation for those final inches of super bowl began? Did the team just show up and poof they won? The boys surmised that planning started back at the draft with questions like ‘who do I need on my team?’, ‘how much money do I have to work with?’, ‘what equipment do I need?’

They got the idea. “Hey isn’t a building a skyscraper Project management?” they asked. “Indeed” I replied. “What about landscaping?” asked another. “That too.” I said.

I then asked them to tell me when they played the role of Project Manager.“Well, I can’t really give you any details” one boy began. “But I did plan to do something and got stakeholders (yes, he used the word stakeholders cause we had just gone over it) and team members to do what I wanted them to do.”

“Great.” I said. “That is exactly my point. The same skills you used there, thinking ahead, planning, organizing a team, figuring out who can do what, and figuring out a schedule, can be refocused and used for good and believe it or not, people need you because of your ability to think ahead, and to lead.”

But I really got into serious project planning with the girls. They wanted to know how to plan. So we did the Who-What-Where-Why questions using their real life need, which is the need to gain more Noyes center privileges through moving up a ‘level’ system. It’s clear that the levels system is Noyes way of encouraging good behavior. They get points for eating, for good hygiene, doing their homework etc.

“So how long does it take to get to the highest level?” I asked.

“20 days.” Said one Girl. “What?” exclaimed another. “You wack. It takes like 5 to 6 weeks.”

“Excellent,” I said, “Let’s do some realistic estimating and activity identification to build a schedule towards your getting towards the highest level” And that led into a discussion about activity identification, activity length and the total amount of points one could get in a day, 100. It takes 2000 points to get to the highest level.

“So,” said one girl, “See that’s 20 days.”

“Ok,” I said, “That’s a good optimistic estimate. But realistically, are you going to have 20 great days where nobody pisses you off and you do everything right.” “No, probably not.” She said.

“So let’s talk about a realistic estimate.” And from there we determined that the 5-6 weeks was a realistic estimate. The girls realized that getting to the highest level was a project and that they were all project managers on their self-improvement project. Further, they defined each other as stakeholders, because they could positively or negatively influence each other’s plan. Finally, they defined the Noyes center as their sponsor and staff as team members.

This wound up being one of the most enjoyable days of my year.    I got to be the geeky PM that I am and at the same time open up a new world of possibilities.   I was most impressed with the kids.  They quickly grasped the basics of Project Management and were able to apply it to not only what they had done in the past, but think realistically about what they could do in the future.

People, Rules and Tools in Baseball and Software Development: A New Way to Think

Driving into work the other day I started thinking about one of the apps I’m managing and how it has become a miss mash of code as developers attempted to code every requirement before true business analysis had occurred. I’ve seen this before –communication breakdowns between developers and business users leading to applications that force business users to change their business rules due to the limitations of the system.

That has always seemed backward to me. The only reason IT exists in the first place is help people enforce business rules and be more efficient in their business processes. It’s the rules first and then the tools. Yet development teams sometimes force business users to adjust or change their business rules and processes to fit into a tool. At least that what was happening on this one project.

For some reason, a baseball analogy popped into my head. It’s like a bat manufacturer was unable to make a straight bat and created a curved bat instead. Then, the manufacturer insists that baseball change the rules to accommodate a curved bat.

By the same token, sometimes business users ask developers to build functionality that only humans should do. That’s like building a tool to determine a strike. You need an umpire, a physical person, to do that.

It’s just silly how things go in software development sometimes. Baseball, however, is pretty clear. You have three basic elements:
People: batter, pitcher, umpire, shortstop, 1st, 2nd, 3rd etc.
Tools: bat, glove, bases, scoreboard
Rules: All the rules of baseball, what a run is, what a ball is, what a home run is, what stealing a base is, how many players have to be on a team, when players can be substituted
In baseball:
• Rules come first and determine how people and tools interact
• The rules (how the game is played) are created by people.
• The rules determine what the tools should be.
• People then use the tools to conduct and enforce the rules.

This means that:
• No tools exist unless its use is specified in the rules
• Rules clearly describe what people are responsible for and what tools are responsible for

The diagram for baseball would look like this:

Baseball People, Rules, Tools

Can this analogy could be applied to software development? The modified diagram would look like this:

Software Development People,Rules, Tools

IT Governance in this model would be Tool Governance. The question from a Tool Governance standpoint would be:

For existing tools:
• What is the purpose for the tool?
• Is the tool linked to a rule?
• Are tools being asked to do what only people can do?

In baseball, tools only exist to enforce the rules and to promote efficiency in the execution of rules.   If we applied this guideline to software development then tools that don’t enforce rules and promote efficiency should be re-evaluated for their necessity.

For the consideration of future tools:
• Does this proposed tool have a rule that it clearly links to?
• Is the rule clear about how the tool should be used?
• How will the tool promote efficiency in the execution of the rules?
• Is the tool designed to do things only people can do?

I like this model because it’s easy to describe and grasp and for that reason, I think I will use it with my executive sponsors . It also brings up fundamental questions that help get to the heart of the purpose of software applications. It simplifies the issues to clarify understanding about why we are building a tool, what people are supposed to do with it and how it supports the business.

Reestablishing Communications on a Stalled Project – Five steps to success

SeaLight, LLC Principal Consultant  Michiko Diby contributed this article to the June 10, 2009 Project Times

Any study on project failure will list poor stakeholder communication as one of the top three reasons for a project’s demise. This brief case study discusses the steps I took to revive project stakeholder communications and move a group of stakeholders from intense distrust to frequent (and pleasant) collaboration.

Background: This web application redesign project for the military had petered to a low level grind, characterized by tersely worded emails, accusations and entrenched opinions. Project status meetings were held monthly, and sometimes skipped. There were no other recurring communications.

Following please find key steps I used to shift this group to collaboration.

Step 1: Perform a Gap Analysis on as-is and should-be communications

The PMBOK version 4 now includes a Stakeholder Management Plan, which should be used by every PM. Many of us PMs were already doing something similar with the communication plan. The key here is to recognize that the PMBOK does have tools that, when used, will actually help you. I used the Communication Matrix and RACI chart to scope out all the stakeholders Just the process of interviewing stakeholders to fill in the RACI chart surfaced mis-conceptions about roles and responsibilities that proved to be the source of many an argument.

Step 2: Use your ability to be impartial as long as you can

When you are a brand new PM on a contentious project, you have a window of opportunity in which you are perceived as impartial; you just haven’t had time to form opinions yet. Use this time to your advantage. I decided to talk to the customer, the armed forces personnel, first. I wanted to understand how they perceived my team before my team could influence me. I knew from my stakeholder review in Step 1 that their experience with each other was based on the lack of clear role definition from the start. I also used this time to clearly understand the client’s perspective on scope, time and cost.

Step 3: Establish your credibility by responding to your action items right away

After my initial set of meetings with stakeholders, I came away with a list of action items. These became my priority. In an environment where trust has been broken, it takes many demonstrations, over time, to regain trust. But you can start off on the right foot but simply responding and responding quickly. Distribute meetings notes right away, do what you say you’re going to do, but do it sooner than expected. If you can’t do it, communicate why and explain when you can.

Step 4: Set up recurring meetings right away

The first thing stakeholders are going to do when they stop trusting each other, is to stop meeting. My job as PM was to get them back in the same room again, stay calm and not take sides. The first few meetings were not stellar. But, I knew that the point is that they actually get face time, even begrudgingly, on a recurring basis.

Step 5: Don’t get sucked in the vortex

In stalled projects, people can behave badly. They will say things that are hurtful and don’t move things forward. Many times I made the conscious choice not to get sucked in. I knew that it took history for negative feelings to develop, and I didn’t have that history. As the new person, I had to be impartial and mature – at times it was a huge struggle to do so. When problems do surface, focus on the problem, not the people. Shift the group to problem analysis, not people analysis.

Result: Within six months of recurring meetings, reestablishment of credibility, slowly introducing proper roles and responsibilities and keeping my mouth shut when I wanted to scream, this group of about 20 armed forces personnel, civilians, and contractors have become re-energized, meeting weekly for a Change Control Board that is effective and collaborative.