5 Tips To Becoming a Great Project Manager

I recently recieved a great e-mail from Brian Cronin at Adaptive Path with some brief yet accurate tips on becoming a great project manager as follows:

What is a manager? What are they really supposed to do? My dictionary provides the following definition:
manager (noun)
a person responsible for controlling or administering all or part of a company or similar organization.

This is the classic understanding most people have of what a project manager is and does, yet I find that it is possible not only to 'control' a project, but also to come up with creative solutions, while enabling your team to become better at what they do. I call this facilitating a project. Here is its definition:

facilitate (verb)
make (an action or process) easy or easier.

The manager is in the center and is the controlling party, while a facilitator is supporting the process and making sure all of the pieces are working together. That is what I do best; facilitating the creative process. Perhaps a more apt title is creative facilitator instead of product manager, account manager, project manager, etc... but I would hate to add anything more to an already overburdened (and over-tilted) role.

Regardless of the title, people in these roles use and share a lot of the same skills. But from the perspective of a facilitator there are a couple of tactics and tips that may not be as emphasized in traditional project management training.

OMNISCIENCE
As a creative facilitator, omniscience is your ultimate goal. Any project, regardless of its complexity, requires an awareness and knowledge of all the various moving parts. You may be called to stand up for unrepresented audiences, are expected to understand the dependencies, and must calculate the schedule impact of any critical failures in the process. While omniscience may be more aspirational than tactical, the tips below can help you get closer to the ideal.

TIP #1 MAKE LISTS: Make lists in notebooks, your email program, OmniGraffle, project sites (I love Basecamp), spreadsheets, and multi-colored sticky-notes. Your lists help make a map of where you are going as well as laying out the directions for how to get there. Lists provide focus in an environment where you are exposed to a lot of information and distractions.

When making lists, consider how re-usable or shareable they need to be. Does each list need to track items to completion or are your lists an aid to commit them to memory? Determining this will help you make the choice between digital and analog formats, as things that need to be tracked are more likely to be shared at one point or another.

BE IN THE LOOP (ALWAYS)
I ask that everyone on the project team 'cc' me on every project related email. My intention is not to have a say in everything, or to be all Big Brother, but to have visibility into everything so I don't have to ask folks "what's going on?” all the time. Often the response to that question results in complex or summarized threads of information. Being and staying in the loop is critical because it allows me to be proactive about addressing issues rather than reactive.

TIP #2 TRIAGE EMAIL THOUGHTFULLY: Consider setting up a filter or tag on the email that you're cc'd on and triage it from the rest of your email. That way you can separate the project related communication stream you should monitor from the project related email that you need to act on. Information is critical but maintaining focus on what you need to do is more important.

KNOW WHAT YOU’RE DOING NEXT
Whatever I am doing, I dig into the details, question assumptions, and know the process to the point of being able to explain things to anyone who asks. I want to always be able to talk about what is going on with my project and why any particular thing is important to the overall objective.

TIP #3 PLAN TO REPLAN: Revisit your plan weekly, not just as a reminder to track progress and be aware of upcoming milestones, but to add new information. Ask yourself, "What might we need to do in the next couple of weeks that isn't represented in the plan?” Make a note of it and ask questions about it. You may uncover risks or identify unforeseen tasks.

KNOW WHAT IS ABOVE AND WHAT IS BELOW THE LINE
Scott Berkun, consultant, friend of Adaptive Path, and author of Making Things Happen, describes his experience as a program manger for Microsoft's Internet Explorer as an exercise in holding the line. Every project has a goal. Every idea, concept, or feature that is developed needs to be mapped to a specific project goal. If there isn't a clear relationship between goals and features then that idea is not included. As Scott would say, it is "below the line". It is critical that I am able to identify what is valuable to the overall solution and what is a distraction. Distractions should be held for another release, another product or another lifetime.

TIP #4 REVISIT THE GOALS EVERY TIME YOU EVALUATE: A project's goals and objectives are your guiding light. Keep a copy of them easily accessible and review them when evaluating progress with stakeholders, and use them before design reviews to set the appropriate context for the evaluation.

DON’T BE A PRISONER TO THE SCHEDULE
Good solutions depend on a process that people can follow. Mapping that process to how people work provides a schedule. Schedules have critical points where decisions need to be made or things need to be handed off to other folks. These are often referred to as Milestones. Milestones are often scrutinized as a measurement of how successful I am at managing the project. For some people, progress is measured quantitatively rather than qualitatively. Are you meeting milestones or not? That’s what they want to know. But good solutions aren't run like a clock. Good solutions adapt to changing circumstances and deliver what is needed for the project to be a success. My job is to understand how to shift tasks, adjust effort, or change dates to make it a success.

Dan Roam, author of The Back of the Napkin, and another friend of Adaptive Path says, "the person who is best able to describe the problem is most likely to be trusted with solving it." This is important not only to win the project assignment, but also to convince people who have already have had their expectations set, to adjust the plan in order for the project to be a success. I don't believe shifting the plan is a sign of failure. The earlier I am able to adjust the approach and move forward, the better I am at my job. I am responsible for delivering the best solution for my clients and I am responsible for making the case for changing tasks, timelines, and resources to do the best work possible.

TIP #5 MANAGE UP USING QUALITATIVE DATA: Breakout of the status report trap. Measuring progress quantitatively is important but the success of the project will be measured qualitatively when it’s done. Incorporate sketches, flows and videos into your reports. Less information is better if you can get people to focus on what is important.

I have more tips that I will be sharing with you in a few weeks, for now let me know what tips or advice you have for project, product, program managers!
""

I really liked this article an I hope it helps at least one person today!
you can find out more about adaptive path on the website.
For more about Digital Project Management click the link or keep reading.

PrinceLite Presentation @ BCS

I was lucky enough to be asked to attend a presentation last night on a newly developed Software Engineering Methodology PrinceLite. PrinceLite was developed by Dr Peter Merrick and the way i see it aims to over come two main problems with project management firstly the excessive amount of bureaucracy and secondly to overcome unclear requirements or as Dr. Merrick puts it unambiguous business requirements specification. He defines some clear benefits of princeLite as the following:

The key benefits of PrinceLite are:

• it addresses cultural and political challenges introducing 'Project Contemplation' as an essential part of the method.
• it integrates the business team and development team through the common language of requirements
• senior management sign-off on prototypes (normally), because people don't read long documents
• only artifacts (products/documents) that add demonstrateable value are produced.
• the basis of all artifacts is pictorial therefore artifacts are short but highly accurate
• method that stresses the possibility of early lifecycle requirements that can be used as part of a rigorous effort estimation programme
• write accurate business requirements specifications that can be used in procurement (tenders, ITT, RFP) to solicit fixed price quotations instead of time and materials estimates
• it is straightforward; although complex (lots of simple elements) it is not complicated therefore it is understandable to a business audience. As an end-to-end approach it delivers unambiguous specifications to architects, designers, programmers and testers.

There are some very good reasons to implement 'some parts' of this methodology but i for one am not entirely sold until i have done more research and can see a greater amount of successful case studies. For more information on PrinceLite can be found at Dr. Peter Merrick's site PrinceLite

Digital Project Management: Born for Agile?

The problem is that every other engineering industry seems to have been around since the masons. The methodologies that were put into place in order to manage the construction of a building or a vehicle were well thought out. These methodologies have adapted and changed making them more versatile while still achieving confidence in the project's success. Now don’t get me wrong, I have no problem with this at all I think they have their place and I think they are very beneficial. The problem is that adapting these methodologies for software engineering has been an uphill struggle. Yes we now have methods that have been used successfully in Software Engineering for a long time now, Prince2 and Six Sigma being the governmental methods of choice for obvious reasons.

The problem is that all of these methodologies were adopted and then modified from other engineering disciplines. Boehm B, was the first to create a formal methodology (CoCoMo) for Software engineering with an aim to manage estimating accuracy. He also adapted methodologies based on the waterfall for more agile developments (Spiral) but these all still have deep rooted problems in the fact that they are based around large software engineering projects developed usually in one language and with one main client. Where am I going with this? Well Digital software engineering is different! The languages and potential functionality are ever increasing, the expected deployment platforms are always evolving and increasing and the display formats and architectures are rarely the same from one day to the next. It is all of these factors that put any rigid management and development at risk. Agile methodologies then seem the logical next step.

The Manifesto for Agile Software Development
states the following:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan:
That is, while there is value in the items on the right, we value the items on the left more.

Donald J. Reifer, has written a methodology based on Boehm's CoCoMo model called WebMo (web Model) which aims to record and calibrate a web development project's metrics after development and based on certain 'predictors of size,' produce estimates of increased accuracy.

Now all of the preceding things I have talked about go a long way to helping us plan, manage and record digital software engineering projects but we are still at risk, why? Due to the number of languages, skill sets and the platform independencies above, not to mention the standard risks any project inherits, par for the course as we all know.

I do not see Agile so much as a methodology, but more a mind set. Yes there still needs to be accurate planning, recording and management, but there also needs to be more emphasis on communication (internally and externally), trust in others abilities and an individual responsibility for the work carried out in order to produce quality working software.

Wheel-of-Tea: Case study
I have recently managed a small yet incredibly agile project. An internal project at Redweb. We have developed an application for the Apple iPhone. The brief was simple, develop an application that records a number of users (people sitting round a desk at work) select what drink options each of them prefer (tea, coffee with sugar etc) then spin the wheel and display the results. We used a form of Agile based on the SCRUM methodology. It was not only an experiment in our ability to develop for the iPhone OS but also in the method we used among lots of other unforeseen obstacles along the way:

The backlog was written. It was simple, prioritised and ready for change, like the example given below:














Working Agile
We were working with a dedicated team and had a very limited time period. Yes you know what this means, time does not change but the deliverables will - this is where agile earns its bread! Going with the Pareto principle we wanted to deliver 80% of the functioniality straight up! And we did. Holding weekly 'sprint' demonstrations of the application to the core stakeholders we were able to re-negotiate the priorities at each demonstration. The one golden rule we had for development is that each week there would be a demonstration and this means every week the build will have to be stable, stable enough at least to demonstrate.

The plans were accurate yet simple and held nothing more than the essentials. The communication was fast and at a much lower level than other projects: This communication was the mortar of the entire project. The development cycles were very much prototype upon prototype keeping the good stuff and trashing the bad.

For all our hard work the project was a success! In terms of delivery 100 percent of the team were happy with the deliverable. The stakeholder is happy with the cost and the small amount of extra time was agreed and well worth it for the extra mile.
Key points for success:
I have read about many successes and failures of using agile methodologies and I think there are a few very good reasons how we managed to use this so successfully. The following points are what you must/must not do if you want every chance of success in your own agile development:

• The key stakeholder needs to attend every 'sprint' (every single one)
• The PM needs to manage (not change the project) but manage the project: Monitor:Record:Report & remove hurdles.
• You need a dedicated and adaptable lead (scrum master, project lead etc) If you do not then the communication will break down.
• Trust: every member of the team must trust in each others' ability to produce the goods and raise issues.
• Work with methodology and believe in the inverse Pareto principle (20:80).
• Prioritise (really prioritise), remember what’s important! If it’s not top priority then ditch it! You can't take everything with you to the end (there will be other versions, let it go from this one)
• Do one thing well, really well. Then modify later with all the bells and whistles
• Know when to stop or when to quit! If you’re not going to succeed STOP. If you've completed your objectives STOP and deliver the damn thing!

Why use Agile?
There are many reasons to use agile but also many reasons not to. Agile unfortunately for some needs a dedicated team, sometime that is not possible. Sometimes the client will not be available or have the commitment to follow such a method. I guess what I’m getting at is that it depends on the project. There are hundreds of failing projects out there using all types of methodologies that have previously claimed "it can’t fail" and hundreds of successful ones using lots of different methods, get out there, find them!

This article will hopefully give you some confidence least of all in the ability to adopt a similar methodology for your next suitable project. If not then at least you can see the potential of using agile based on the example given here:









Designed and Developed by RedWeb
Methodoligy used: Hybrid Agile
Development Time: Confidential
Website: http://www.wheeloftea.com
Twitter: http://twitter.com/wheeloftea

How does it work?



1. Add the names, photos and drink choices of your friends




2. Shake your phone to spin the wheel and decide the loser of this round









3. They must then head to the kitchen to get everyone’s drinks




4. Start again next time you’re thirsty!







Share us with friends:
Facebook | Delicious

iPhone application for cuppa tea | iPhone tea application | Iphone application tea rounds

50 Great examples of infoGraphics

Exactly what is says on the tin! Follow this link to see 50 great examples of infoGraphics
50 great infographics