Strategic Project Management

Learning project management best practice doesn't just happen. Especially for those who don't come from the traditional IT project portfolio management background.

Over the last couple of years I have noticed that there is a lot of project-based work accomplished by managers who aren't formally trained project managers as companies turn to projects for increasing productivity. Because these "accidental" project managers are often left to themselves to figure out the best ways to manage projects, motivate teams, and get work done, searching out information to help learn best practices becomes critically important. That being said, some of those "accidental" project managers turn out to be incredibly effective and some of the most intuitive and successful managers.

Without getting into a discussion about certification and formal training, there are other ways for budding project managers to learn the ropes. (Anyone considering the path of the PMP should talk to Josh Nankivel at PM Student or Derek Huether at HueCubed, both of these guys are great resources for preparing for the PMP exam.) I'd like to talk about some less formal ways we share information and learn best practices.

Anyone who has read this blog for any length of time knows that I am a big supporter of the social network of project managers on Twitter who so willingly share valuable information with the rest of us. There is a tremendous amount of really good, real-world information, available to anyone who is willing to do a little bit of digging. There are excellent blogs, webinars, user groups, conferences, tradeshows, and seminars. In fact, it's never been easier to learn how to best implement sound work management methodologies within your organizations.

I think this almost instantaneously available information benefits the project management community. We are very fortunate as project professionals that there are so many talented and capable people willing to share their insight into what makes successful projects click and what it takes to be a skilled project leader. I believe this "community" lifts the profession and creates greater perceived value in the workplace.

I know that I enjoy the time I spend with my peers in person, on the phone, and even online. I think it helps me be better at what I do and inspires me to share with the rest of the community. As I talk to people about what makes them successful, it's rarely a discussion about software (although the right software tools contribute to project success). It's usually about implementing sound methodology and best practices.

Why don't you give it shot. Ask a question via someones blog or on Twitter and see how willing they are to help you find an answer. You might be surprised at how quickly someone who normally charges hundreds of dollars and hour in consulting fees will step up to answer your question.
 

Managing stakeholder expectations is an important part of managing project-based work. If you're lucky, project stakeholders have clearly defined the value of what the successful outcome of their project might look like. I say lucky because unfortunately, clearly defining the potential value of an initiative before the project has begun seems to be the exception rather than the rule in most organizations. However, if success is not clearly defined, it's up to the project manager to initiate a dialog to determine the value and desired outcome. Otherwise it's difficult to successfully complete any project. And what's more, it's never a good idea to be measured against a moving target.

In most organizations, a stakeholders attention span is pretty short. Long projects that require a lot of stakeholder patience tend to falter and ultimately fail. Providing value regularly, at short (3-4 week) intervals, keeps stakeholders engaged and interested.

It's sometimes easy for change orders to morph a project into something different than what was intended. Keeping stakeholders focused on the objective can be challenging, but it's critical for project success. If a change doesn't contribute to the defined objective, stakeholders need to understand the ramifications and how changes could impact the final outcome.

When reporting to stakeholders, it's important to remember that executives aren't as interested in your particular work management methodology as they are in results. Keep stakeholder communication focused on progress and value. Be concise and brief. Sending a lot of time buried in the details with stakeholders will not only be frustrating for them—it doesn't do you any good either.

Four keys to managing stakeholder expectations:

1. Make sure "project success" is clearly defined before the project begins
2. Don't make stakeholders wait too long before they start to see value
3. Execute against the objective to ensure project success
4. Keep it simple when communicating with project stakeholders

Although none of these suggestions require project management software, they will keep stakeholders informed and happy. I'd welcome hearing what some of you are doing to manage stakeholder relationships.

I'd like to talk about the Nintendo Wii.

Earlier in the month I wrote about how approaching software design from the perspective of an anthropologist was a good idea in Project Management Software Development: A Fresh Look From a New Perspective. I'd like to continue that discussion by talking about how we, as software users, sometimes struggle with what we really need vs. what we think we need—and how software designers need to somehow figure out the best way for us to interact with the software. (I think this applies whether or not we are talking specifically about project management software. As an industry, PPM software just happens to be a really good example of a failed development process.) As I describe in the previous post, human behaviors are pretty complicated things to measure. There are so many variables associated with how we react to different situations that it's difficult to quantify our behaviors in a way that can be illustrated in a graph or spreadsheet.

Love it or hate it, the way my Nintendo Wii was designed is a good case in point. Genyo Takeda*, the general managers of Nintendo's integrated research division, said the following about the possible consequences of allowing convention thoughts about video game design to control the development of the Wii:

500 annual projects sounds like a lot of work.

In a recent conversation I had with a project manager for the marketing department of a leading online and offline retail chain, I was told that she and her staff of 10 project managers handled 500+ marketing projects per year. Even with the understanding that marketing projects are often of shorter duration than a large IT project, I was still impressed (that averages to two new projects each week). Not all marketing projects are of short duration, and many rival the complexity of a large IT project.

As we discussed what they were doing to manage projects, their goals for improving the way they approached project-based work were very similar to how a traditional IT organization might look at work management. This conversation validated in my mind the notion that there are many organizations turning to traditional IT project management processes to improve efficiency and get more work done regardless of they type of work they do.

I don't think this comes as a surprise to anyone. I think most of us in the project management industry have recognized that PPM isn't just for IT anymore. However, at the end of our conversation she made a couple of observations that I think are very relevant for software providers:

1. They spent four years looking for the right solution for their marketing department.
2. It was difficult to find a solution that spoke to the needs of creative departments.
3. They would like to see something that would be more conducive to an audience of creative thinkers. Something that was more visual, included a more creative color pallet, and was simple to use and more straightforward in approach.

I've heard these same suggestions from IT project professionals, but as project management methodologies expand outside of IT I think it becomes even more important to approach the project management process from the perspective of the user. This is something I find myself talking about on a pretty regular basis because I believe the end user is the linchpin to project management software adoption and success. I most recently talked about this in a post titled, Overcoming the Knowledge Worker Assembly Line.