I just bought an Apple MacBook Air. As a Windows power user, I worried some about transitioning from my Windows environment to this newfangled, alien-looking device. Happily, it has been a no-brainer. Although I haven't figured out everything, I've embraced the Mac environment relatively easily, despite the fact that Microsoft has entwined itself in my DNA over the past two decades. I'm very happy with my new friend.
Finding the right MacBook case, however, is a different story. I don't know if I want a neoprene zipper bag or an over-the-shoulder messenger bag or the case that disguises your MacBook as a hardback book to confuse potential thieves. It must be light, and it must be fabulous. After hitting more than ten sites with many options but no way to filter for my needs, I think I'll make my own.
This project manager was strong, motivated, and driven to succeed. She was certified, the PMBOK was her friend, and she could create the most amazing Gantt charts ever seen.
One day, she took on a new project.
This project was large and complex. It involved new technologies and many stakeholders. And the project team was — let’s just say — “challenging.”
But this didn’t scare our heroine. She created a fabulous Gantt chart, established milestones, and documented roles and responsibilities. She set up her cost management, time management, and quality management plans. And she doled out assignments to the project team with a confident smile.
The project went off track quickly.
Team members argued, stakeholders failed to participate, and serious roadblocks emerged. The project manager requested status updates, set up meetings, and reported to the steering team — all things that “good” project managers do. But eventually, she lost the gig.
Why? She either didn’t have — or didn’t use — critical soft skills that today’s strong, next-generation project manager absolutely must not only have — but also exercise.
Like this project manager (any resemblance to actual events or characters is purely coincidental), I come from a very “traditional” project management background. I’m a PMI member and a certified project management professional. The PMBOK is my friend too. Managing the triple constraints of time, cost, and scope motivated me for years. And while my traditional project management skills helped me lead most (but not all) of my projects to successful outcomes, they would have meant nothing without the ability to serve and enable the team, adapt to complexity, and flex appropriately.
Oh wait...it's only June 30th. Wow. I sure feel like I've tried to cram twelve months of work into six months of time (with varying levels of success). And sitting here at 2010's halftime show, I wonder what the second half will bring.
But before we spend too much time plotting our second-half strategies, let's look back at the first half's highlights.
A couple of days ago, Texas Stadium was reduced to a pile of rubble. Wow. The former home of my Dallas Cowboys, the site of victories and record-setting performances — gone in a matter of minutes. Was I sad? Yeah. But also a bit relieved. The Cowboys have moved to their new, super-duper (and quite ostentatious) stadium, Texas Stadium memorabilia has been auctioned off, and the poor, neglected building had become quite an eyesore.
Sometimes destroying something unusable is the best way to move forward.
Run that statement past your approach to documenting software requirements. When was the last time you took a step back to evaluate how your organization represents requirements? If it’s been awhile and your business analysts are still delivering massive, text-heavy, all-encompassing business requirements documents (BRDs), it’s time for some demolition of your own.
Why? Compelling forces have converged, drastically changing the way application development teams author software requirements. Organizations are recognizing the connection between software failure and poor requirements, and authoring better requirements has become a major initiative in many firms. At the same time, Lean and Agile are front and center, so right-sizing requirements documentation is on everyone’s radar. Bottom line, you need to do more with less: author stronger requirements while minimizing waste and being as lean as possible.
I was catching up on my reading over the holidays and came across an intriguing article in my December issue of PM Network magazine. It began like this:
"As their role changes, project managers must acquire new skills - or risk being left behind. It's a whole new world out there for project managers..."
Hallelujah, I shouted! Having recently published research on the skills and capabilities of the next-generation project manager, I couldn't agree more. Changes to software delivery necessitate a reinvention of the project manager role. In the world of app dev, we're seeing that:
During my first year as a Forrester analyst, one widespread pain point has made itself apparent: IT leaders wrestle with the subject of metrics, particularly in these challenging economic times. Most people I talk with are effective at collecting and reporting the basics: project on-time and on-budget performance, application up time, and help desk call statistics. But other measurements are more difficult to engineer. And there are so many things that can be measured; it’s difficult to figure out which ones really matter and are worth the time needed to collect and report them.
Like many around the globe, I've been watching the summer Olympics. And I’ve been struck by two realizations.
The first is obvious, but interesting. Olympic athletes vary greatly in culture, size, and sport, but also in age. A fourteen-year old British athlete partnered in a synchronized diving competition with a man 12 years his senior. And the oldest female gymnast in the Olympics performed - quite competently - next to athletes less than half her age of 33.
The second realization? We see these individual athletes age – and mature – in four year increments. Witness Michael Phelps. Four years ago he was a lanky American, who won a bunch of races. This summer, in Beijing, he displays a maturity brought on by four years, a champion’s focus, and the support of coaches, family, and teammates. The result? An Olympic legend.
So what constitutes “maturity”? Is it age? Experience? Or are those measures irrelevant? And how do you know that you're "mature"? How do you know that you're doing things the "right" way?