The “best”

July 15, 2013

By  via   Article

Why Implementing Project Management Best Practices Means Something Different for Everyone

“Project management exists in literally every occupation — it’s the definition of ‘project’ that changes. … For project managers, implementing best practices isn’t about fitting their project into predetermined outlines, but instead, stretching and molding good advice around the specific needs of the project so that it can be completed successfully.

Basically, it doesn’t really matter if the approaches a PM chooses are unequivocally the ‘best,’ so long as they consistently bring about positive results.

Making Best Practices Work for Your Project

Once established, versatile project guidelines and a killer team still might be left with a few questions about implementation. According to Cardinal Solutions, actualizing processes comes down to four things:

  • Identifying those approaches, processes and tools that, when applied correctly, always lead to positive outcomes.
  • Building a PM team that has the skills and ability to apply company best practices to actual projects, not in theory but in reality.
  • On-going training that covers best practices and potential risks.
  • Reinforcing training theories and concepts by applying them to real projects.”

Stop Pissing Off The Engineers

July 8, 2013

By Brian de Haaff via the Aha! Blog    Article

Hey Product Managers — Stop Pissing Off The Engineers

“So you are the product manager — CEO of your domain — and the go-to-guy for everything that matters. You help set the strategic framework for where your product and the business are headed and lead a cross-functional team to greatness. You see the big picture and can muck around in the minutiae with the best project manager around. … You are a rational force and a creative artist. You converse with every tribe, including customers, marketing, sales, support and every other stakeholder group that your product depends on to win in market.

… great product management is usually the difference between mediocrity and awesome. While nobody would miss product management if it (and you) disappeared in the short term, ensuring product alignment with business strategy, market opportunity, and customer need is what superstar PMs do in market leading companies.

However, the reality is that you need engineering more than they need you. They can continue to crank out product without you (and be happy doing it), but you can not write a line of code yourself. Engineers are the manufacturing engine that drives the business forward and are the most important non-customer asset in the company. You are overhead.

consider the following five common ways that PMs piss engineers off every day. It’s a chance to pause and truly reflect. Be honest, which ones do you do? It’s a bit like body odor, self examination and fearless honesty matter.”

“it’s better to be a pirate than join the navy”

October 15, 2012

By Matthew E. May in Fast Company   Article

The Rules Of Successful Skunk Works Projects

“When Germany’s first jet fighter planes appeared in the skies over Europe in 1943, the U.S. War Department hired Lockheed Aircraft Corporation to build a working jet fighter prototype, giving it just 180 days to do so. … Challenging constraints shaped the project: build a jet fighter prototype that would fly at 600 miles per hour–the edge of the speed of sound and 200 miles per hour faster than the current Lockheed P-38 propeller plane–in 180 days. …

He [Kelly Johnson] broke away from the Lockheed main operation, taking 23 of the best design engineers and 30 mechanics with him, and set up camp in a rented circus tent next to a foul-smelling plastics factory, figuring the odor would help keep nosy parkers away. … Perhaps it was the stink that drove Kelly’s secret team to design and build the prototype for the P-80 Shooting Star–nicknamed Lulu Belle–in a mere 143 days. That’s 37 days ahead of schedule. …

Thus was born the de facto standard for running top secret projects among the world’s most innovative companies, and the model [Steve Jobs] used in launching the Macintosh division of Apple. In his biography of [Steve Jobs][Walter Isaacson] tells how Jobs cherry-picked a team of about 20 “pirates,” as he referred to them, and seceded from the Apple main campus. He relocated the team to a small building three blocks away, next to a Texaco station. The two-story brown-shingled building became known as Texaco Towers. Jobs kept the renegade spirit alive with his maxim “it’s better to be a pirate than join the navy.” Jobs actively recruited rebels and swashbucklers–talented but audacious individuals who could move fast and get things done.

Over the years, the term Skunk Works has come to refer to any effort involving an elite special team that breaks away from the larger organization to work autonomously on an advanced or secret project, usually tasked with breakthrough innovation on limited budgets and under aggressive timelines.”


Declaring victory

January 23, 2012

By Seth Godin   Article

“Whenever you start a project, you should have a plan for finishing it.

One outcome is to declare victory, to find that moment when you have satisfied your objectives and reached a goal.

The other outcome, which feels like a downer but is almost as good, is to declare failure, to realize that you’ve run out of useful string and it’s time to move on. I think the intentional act of declaring becomes an essential moment of learning, a spot in time where you consider inputs and outputs and adjust your strategy for next time.

If you are unable to declare, then you’re going to slog, and instead of starting new projects based on what you’ve learned, you’ll merely end up trapped. I’m not suggesting that you flit. A project might last a decade or a generation, but if it is to be a project, it must have an end.”

Seven new year resolutions for project managers

December 26, 2011

By Dr. Andrew Makar  Article

1. I will update my project schedule weekly and share the updated plan with the team.

The project schedule is one key document that needs to be revisited every week as project teams report progress. Project schedules are not intended to be cast in stone but rather serve as a forecasting tool that can adjust and incorporate re-planning. Spend 30 minutes to an hour a week updating the project schedule, reviewing it and obtain input from the team on scheduling changes.

2.  I will document meeting minutes and send them out by the end of the day.

I know we all abhor meeting minutes, and transcribing them from scribbled notes into a meaningful MS-Word format can be a challenge when the day is packed with meetings. If you don’t get your notes and key action items out by the end of the day, they will likely fall behind–and few people respond to late meeting minutes. That’s why I advise using a mind mapping tool to document your meeting minutes and send them out that day. (Consider this article, Mind Map Your Meetings, on how to incorporate just-in-time meeting minutes into your day.)

3.  I will send out my meeting materials the day prior, not five minutes before.

I will readily admit I am guilty of sending out key materials a few minutes before the meeting so everyone has the latest copy. The problem is that some documents need to be reviewed or printed before discussing them in a meeting. I’ve been in a few meetings where executives chastised the project manager for not sending them out earlier so they could review the materials. To avoid this embarrassing situation, I send out the materials the day before (maybe at 11:59 at night…but at least I’m avoiding the appearance of being unprepared as I implement just-in-time meeting materials). …

5. I will encourage my management to conduct “skip level” meetings with my team members.

Successful project managers can’t deliver unless they are supported by a team. Project managers should recognize their team members and share the accolades within the management spotlight. One way to do this is encourage your manager to have skip level meetings with your project team members. It will give your team members some additional visibility to a manager or executive that may not know specifically how your team contributes to the organization. It also provides an opportunity for team members to provide unfiltered feedback and new ideas. ….”

Looking for the right excuse

June 13, 2011

By Seth Godin  Source

“This is the first warning sign that a project is in trouble. Sometimes it even begins before the project does. Quietly, our subconscious starts looking around for an excuse, deniability and someone to blame. It gives us confidence and peace of mind. [It’s much easier to be calm when the police car appears in your rear view mirror if you have an excuse handy.]

Amazingly, we often look for the excuse before we even accept the project. We say to ourselves, “well, I can start this, and if it doesn’t work perfectly, I can point out it was the …” Then, as the team ramps up, bosses appear and events occur (or not), we continually add to and refine our excuse list, reminding ourselves of all the factors that were out of our control. Decades ago, when I used to sell by phone, I often found myself describing why I was unable to close this particular sale–and realized I was articulating these reasons while the phone was still ringing.

People who have a built-in all-purpose excuse (middle child syndrom, wrong astrology sign, some slight at the hands of the system long ago) often end up failing–they have an excuse ready to go, so it’s easier to back off when the going is rough.

Here’s an alternative to the excuse-driven life: What happens if you relentlessly avoid looking for excuses at all? Instead of seeking excuses, the successful project is filled with people who are obsessed with avoiding excuses. If you relentlessly work to avoid opportunities to use your ability to blame, you may never actually need to blame anyone. If you’re not pulled over by the cop, no need to blame the speedometer, right?”

When do teams make sense?

May 16, 2011

From Daily HR Tips  Article


“Many organizations have embraced the team concept wholeheartedly. But as it is with most things, there is also a negative side to teams.

Teamwork takes more time and often more resources than individual work. Teams have increased communication demands, conflicts to manage, and meetings to run. So the benefits of using teams have to exceed the costs, and that’s not always the case.

How do you know whether the work of your group would be better done in teams? You can apply three tests to see whether a team fits your situation.

  1. Ask yourself can the work be done better by more than one person? A good indicator is the complexity of the work and the need for different perspectives. Simple tasks that don’t require diverse input are probably better left to individuals.
  2. Ask yourself does the work create a common purpose or set of goals for the people in the group that is more than the aggregate of individual goals? Many service departments of new-vehicle dealers have introduced teams that link customer-service people, mechanics, parts specialists, and sales representatives. Such teams can better manage collective responsibility for ensuring customer needs are properly met.
  3. Determine whether the members of the group are interdependent. Using teams makes sense when there is interdependence between tasks—the success of the whole depends on the success of each one, and the success of each one depends on the success of the others. Soccer, for instance, is an obvious team sport. Success requires a great deal of coordination between interdependent players. Conversely, except possibly for relays, swim teams are not really teams. They’re groups of individuals performing individually, whose total performance is merely the aggregate summation of their individual performances.”