Like Project Management? Like Game of Thrones? Perfect! Read my new post on geekwire!
I came across a cringe-worthy headline this morning that described a design mistake in the 520 bridge plan that will end up costing between $100-$200 million dollars. I pretty much knew what the article was going to say before I read it:
“The state chose to design the pontoons itself on a fast track (rather than delegate that responsibility to contractors) as a strategy to attract lower bids and to get the floating section built by 2014, a timeline set by former Gov. Chris Gregoire.
Initially the strategy seemed to work, as the winning bid to build 33 pontoons at Grays Harbor, for $367 million, was $180 million less than the state expected to pay otherwise. But now, taxpayers and toll payers will surrender much of those savings.”
Where have I heard this before? Oh right, almost every project.
For some reason, clients and project sponsors–internal or external–seem to think that one of the easiest places* to save money is skimping on good project planning steps. This always, always comes back to bite the participants in the ass. I hate to use cliches, but “penny wise and pound foolish” and “if you fail to plan you plan to fail” are actually applicable.
As a PM, I’ve put together project proposals that include planning phase(s) and oftentimes they’re met with the attitude that proper planning and requirement gathering is unnecessary overhead, a buffer to pad the schedule, and/or a cynical way to squeeze more money out of the client. While these fears aren’t 100% unfounded and should be mitigated, the fact that subverting a solid foundation from which to build is a terrible practice.
This is where phrases like, “where did this dependency come from?” or “we didn’t know we needed accessibility standards and testing,” or “what do you mean it won’t work on our existing hardware?” are born.
The DOT creating the 520 bridge design in-house is common, and one of the less egregious examples of cutting corners. They saw an opportunity to “save money” and decided not to entrust the design to experts, who would have, I’m sure they assumed, gouged them. This isn’t uncommon, nor is it the worst type of offense. I’ve literally heard the phrase, “can’t you just build it?” in response to project plans. One proposal was met with something along the lines of how rather than spending money to plan what the product was going to be, we could just use that money towards development. These are sentiments from actual adults, and the saddest part about it is that I’m not surprised by it anymore.
While I’m a huge proponent of agile methodologies, one of their drawbacks is that some organizations see it as carte blanche to skip planning. This isn’t actually agile, but agile’s evil twin named “undocumented waterfall.” A good agile program does not skip planning, it plans constantly in multiple phases–the largest of which is at the beginning. For a great example, I just read an awesome blog about UX effort in agile which shows the application of non-development effort in an agile environment–you know, planning how things should work before they’re built. Weird, I know.
I’ll end with the fitting quote from Paula Hammond, Washington Transportation Secretary:
“Everybody wants you to take risks, until something goes wrong.”
Originally published on FNX Studios Tech Log, May 14th, 2012.
The Velvet Glove
I’ve been asked occasionally by friends and associates what it’s like to be a PM* in the software development game. Whether it’s a good job, if I think being a PM is a good career path for him or her, etc. I love answering this, because it’s a profession and set of philosophies I’m very passionate about. It can be a really fun and rewarding job—for the right person. You have to feel good about the teamwinning and be comfortable with personal accomplishments that are less tangible than creating a sculpture or writing a distinct piece of code. There’s a big difference between managing a project and being a PM. You have to feel it in your bones—people can smell it on you if you don’t.
Here are some thoughts and, as we say in the biz, “lessons learned.”
The worst-kept secret about being a PM is that the nuts and bolts of the job are important, but pretty easy. The schedule calculations can be done by anyone who isn’t an idiot (and even by a few who are). Maybe you’ve always suspected this, too. Maybe you’ve even asked a PM what his or her job consists of, and he or she told you that it’s managing the “iron triangle” or “triple constraints”:
Scope – what needs to get done
Schedule – when it needs to get done
Budget – how much it will cost
Easy, right? But, how much actual authority does a PM have to control these? Oftentimes, very little. Have you ever seen a project go perfectly according to plan? Probably not. If you want to know what being a PM is like, don’t ask him or her what the job description is; ask what is pissing him or her off right now.
PMs can’t make unilateral decisions about any of the three corners of the triangle, even if they are the right ones. In most organizations, PMs don’t have the authority to hire and fire. Decisions are made and overturned by senior leadership, which oftentimes run contrary to the PM’s plans—in the most frustrating cases, this happens without his or her knowledge. The truth is that while the PM position does not have much granted authority, it does have very real accountability for the success of a project.
I struggled with these concepts for a while as a junior PM; “If only these people would stop messing with my project, everything would be perfect!” But, adjusting to these imperfections without negatively affecting the project and the team is the job.
Some PMs want to solve this problem by being granted more authority, as if to wield the iron triangle like a fist. I prefer to be the velvet glove. A good PM doesn’t need to be granted authority to have the power to help ensure a project’s success. As a wise man once said, “power resides where men think it resides.”
Do The Right Nothing
Many PMs get caught up with the process instead of with the people. There are best practices, sure, but hammering them down the throats of intelligent people who just want to do their jobs without impediments will hurt your project rather than help it. A project that emphasizes people over process fosters an environment in which it’s fun to work.
Software development is a creative job. Most of the engineers I know actually love writing code; many of them hate everything else that goes along with it. Constraints like in-your-face deadlines shift an engineer’s focus from the code to the clock, which hampers creativity and can encourage cutting corners. Administrative tasks and meetings are distracting.
People want to get to a state of flow. This means that you, as a PM, need to remove obstacles before they pop up, while not getting in the way yourself. You need to do everything that isn’t the measurable work, so that people who are doing that work aren’t distracted with unimportant minutiae. Learning when to intervene and when to stay out of something is a delicate dance. As god once said (in Futurama), “when you do things right, people won’t be sure you’ve done anything at all.”
If that all sounds too touchy-feely for you cynics out there, just remember this: processes don’t do the work, people do. Happy people do more work, unhappy people do less, or leave.
“What’s the Point of this Meeting?”
If you’ve worked in an office setting, you’ve been to a boring meeting. This is epidemic. I’ve actually seen people cringe at the sight or mention of a PM because of their association with terrible meetings.
Some meetings, of course, are necessary—and even beneficial! How do you know? Ask yourself:
Is this meeting for me or for the team?
If it’s for you, then the team won’t want to be there—they want to be working, not herded into a room to give you status. If the meeting is for the team, such as a planning session or to whiteboard a problem, usually people will recognize it as productive.
Administrative tasks are the same way. Do you create reports and schedules because you have to, or because it’s useful to the team? When should you involve them?
A good PM edict regarding engagement with his or her team can be summed up thusly:
“Everything I do with the team is for the team. Everything I do for myself, I do by myself.”
A Professional What?
Obtaining your PMP, CSM, or other certification is great for learning about the craft, but it doesn’t make you a good PM, nor will it guarantee you a job—just like creating a perfect project schedule doesn’t mean your project will be on time.
Here, too, people are the key to success. Build relationships; network. An impressive CV is less important in the hiring process than connections and cultural fit because a PM is a personality driven job. No one chooses to work with the iron fist PM.
You can probably ignore the rest of the article and still be alright. Seriously. Bring donuts.
*I’m using the term “PM” as a blanket term for various flavors under the project management umbrella for software dev–Program Management, Project Management, Scrum Mastering, etc. There are differences between those roles, but not relevant to this discussion.
Originally published on GeekWire, January 23, 2012
Have you ever been playing Halo and realize you have no clue where the next objective is? You just killed the last Gold Elite or Promethean Knight and… now what? Just as you start thinking, “Where do I go now?” the watchful eye of your partner Cortana gives you the, “The door is this way, Chief,” nav point on your HUD. Of course, it was so obvious! How could you have missed that door? On the flip side, Cortana’s not nearly as good with an assault rifle–she’d be useless on the battlefield without you, despite all her snark. Both of you bring something to the universe-saving table.
Have you ever been stuck on a code problem you know you can solve given enough time and thought? You’re a great developer. You’re a genius! You’re good enough, smart enough, and… well, you know.
You get up and walk around, think about the problem,
check your email, think about the problem,
get coffee, think about the problem,
check Facebook, think about the problem,
go home, think about the problem,
go to sleep, dream about the problem.
Eureka! You’ve got it!
You’ve also got one less day until your deadline.
Sure, you could have poked your head over your cube asked a peer, your lead, or your manager for advice. But if you can solve the problem, why waste their time and make yourself look incompetent and needy? Besides, what do those jerks know that you don’t?
As a PM, I have seen this happen over and over. It’s why I’m a big advocate of Pair Programming to eliminate this social barrier and to add a host of other benefits.
How does it work? Two Developers, one workstation.
One assumes the role of the Driver, who is physically coding and focuses on the tactical aspect of the code. The other is the Observer / Navigator, who reviews the code in real time and has a higher level strategic view of where the code needs to go. These roles switch back and forth throughout the day and facilitate conversation within the pair.
One is focused on the big picture, the other is focused on headshots. Problem(s) solved.
It may seem counter-intuitive to burn two developers on a single task, but studies have shown that the end result is higher quality code, better productivity, and more code coverage. Pair Programming provides a systematic way to achieve unmatched knowledge sharing.
As a developer, you bring something unique to the table. Share that knowledge, become stronger, and maybe, just maybe, you might save the universe.*
*you will not save the universe.