We're All in Sales

Daniel Pink was the keynote speaker at this year's PMI Global Congress. I have blogged about him in the past (here and here). His presentation this time was based on his latest book, To Sell is Human.

As the title implies, a main theme of the book is that we're all doing sales of some sort, even if it isn't in our job title. I thought about the times I've been working with a new customer and trying to "sell" them on agile and why they should start using it to run their projects. He had six pointers to help us as sales people

1. Extroverts aren't better than introverts at selling. It's really the people that are in the middle that are the best sellers. They balance talking and listening the best.
2. Interrogative self-talk is the best way to prepare for something like an important meeting or presentation. Don't think "I can do this" ask yourself "Can I do this" and answer in a way to convince yourself.
3. When we're trying to sell, compare it to something else. So compare agile to waterfall and explain why agile is better.
4. Related to that, less options are better than more options. Pink told a story of an experiment selling jam. When there were over 20 types to sample, people sampled a lot but bought less than when there were only 6 types because is was easier to decide which ones they liked best.
5. A minor negative attribute can help sell. So if you have these great shoes with a lot of desirable features, but they only come in 2 colors, this small negative will actually help you sell. You come across more open.
6. Have more conversations about why than about how. 

I had a chance to chat with him briefly during a book signing. When I mentioned agile project management, he said he thought agile would become the only way to run projects. I haven't finished his book yet, but I still recommend it. I even used the technique in #2 to prepare for a big client presentation yesterday and the presentation went very well. 

Tailoring Agile

I came across a Software Advice article based on an interview with Ryan Singer, Product Manager at 37Signals. I used their Basecamp tool on a project not to long ago and found it to be a pretty good tool.

In the article, Singer talks about how they organize work on a project. Instead of assigning all the tasks by roles, they organize the work around what Singer refers to as projects...but I would call them features. Using their example, one of the projects (features) of a conference registration application would be a receipt page. They prioritize the work by each of the features or what they refer to as areas of concern.

To me is sounds like they are taking more of a Kanban approach, prioritizing the features and working on them one at a time rather than planning work around iterations. I also didn't see an reference to User Stories.

I took my PMI-ACP certification exam earlier this year, and in my studies came across a discussion of process tailoring in Mike Griffith's exam prep book and the concept of Shu-Ha-Ri, which I blogged about a while ago myself. It seems like the folks at 37Signals have done some tailoring that has worked for them, but is their approach right for everyone? Probably not.

In the spirit of Shu-Ha-Ri, you should start by following the rules. For most people, this probably means Scrum. From here, you need to figure out which rules to break for your organization. Researching what other organizations like 37Signals has done is good for ideas, but ultimately you need to figure out what works in your organization. As Singer points out, there are many creative ways to use Basecamp, just like there are many creative ways to tailor your agile processes to meet your organization's needs.

Getting Unstuck

I have an app on my iPad that I turned to today to help me get past a little writers block. I haven't been posting to this blog much because I haven't had any good ideas. The tool is called Unstuck, you can find out more about it here.

So I went through a set of exercises that helped me define why I was stuck, and then helped me think through why I was stuck and come up with a plan to get past it.

One of the exercises it suggested was writing about the future. The idea is to think 5 years ahead. You are on the cover of Time magazine. What would the article be about? Now think 10 and 15 years ahead. After you've envisioned some future state, think about the smaller steps that would get you there, and that is the basis for getting unstuck.

The app has a lot of different tools for different situations. Mirror Mirror helps you set goals when you're drifting. Get Your Game On helps plan and prioritize. Now or Never helps you get motivated, and there are others. So if you're having a stuck moment, I recommend looking at Unstuck.

Agile Isn't New

When I was in the US Navy, one of my assignments was working with the U-2 spy plane and the folks at Lockheed Martin, famous for their Skunk Works program. I was recently researching the program for some training I was doing, and realized how closely the principles of Kelly Johnson aligned with the principles of agile.

Skunk Works came about in 1943 as Lockheed (as they were know as then) was working on the first jet fighter. Kelly Johnson was a young engineer on this program. He outlined his 14 rules & practices to  guide the teams. Some of the key points include:

• The manager should have practical control of the program (think product owner)
• Use a small number of good people
• Use very simple drawings with flexibility for making changes
• Minimize reporting to what is important
• Mutual trust between the military project organization and the contractor

Now some of the other rules related to the relationship between the vendor and the government, but this list sounds similar to some points in the Agile Manifesto and Guiding Principles. I don't know if the work of Kelly Johnson influenced the people that wrote the manifesto, but it's clear the ideas have been around for a while. And as far as a track record, the original fighter plane (XP-80) was designed and built in 143 days, and the U-2 has been operational for almost 60 years.

Retrospectives

I mentioned in my last post that I'm on the blog team for the PMI Netherlands Summit, taking place June 13th in Zeist - The Netherlands. One of the sessions is on retrospectives; it's titled Retrospectives: your lessons learned on steroids to help your team / project in your continuous improvement. 

A key tenant of agile projects is to inspect and adapt and that is the purpose of retrospectives. We use these as opportunities to help us identify ways to improve. We should be conducting retrospectives on a regular basis, normally at the end of each iteration.

This past weekend I was at the PMI Leadership Meeting for the communities. After the official program ended, the Agile Community got together and had a retrospective of our work since our last time getting together. The idea of retrospectives can be applied to operations as well as projects. The idea is the same, pick a time, take a step back, and think about how you can work together better. We came up with some actions to help us better deliver value to our customers going forward. You should try it, and if you don't know how, maybe you should think about attending the conference.

Learning Outside the Box

I'm on the blog team for the PMI Netherlands Summit, taking place June 13th in Zeist - The Netherlands. One of the tracks is Learning from Outside the Box. I appreciate the aspect this track is taking. Sometimes you can learn valuable lessons when you get outside your normal area of focus.

I recently spoke at a conference in the US that focused on health care, the HIMSS conference in New Orleans back in March. Some of the attendees of my session were familiar with agile, but many were not and based on my audience, agile was not being used much in healthcare. For them, this was a learning outside the box experience, but also for me.

I have not done any projects in the healthcare field. I learned something about the field based on the questions my audience was asking. It has peaked my curiosity and I've started researching the types of projects that this industry deals with and started thinking about how agile can support this field.

So if you're in the EMEA region and looking for a good conference, check out the PMI Netherlands Summit. There are some strong speakers such as Dr Lynn Crawford and Dr Terry Cooke-Davies and a lot of interesting topics.

Dos and Don'ts of Time Management

This guest post is from Steward Copper of Project Management Insights

Show me a person who wouldn’t like to become successful in life and his career. We all want to become winners and overcome others in the competition. We want to achieve some goals, become famous and get into the top list of the ‘winners’.

But it isn’t easy – the road to success and prosperity is really hard and it isn’t a bed of roses. You need to be ready to work a lot in order to achieve your goals. The most valuable thing that we all need – and which we always lack - is time. Although there are only 24 hours a day, some people manage to do more things than others. How do they manage it? They apply time management principles and know how to prioritize tasks and issues. Remember, that your big goal is a combination of smaller goals that you have to achieve on the way to your own ‘big goal’.

No matter who you are – a student, a teacher, a businessman, a project manager, or a housewife – you need to learn how to manage your time efficiently. I hope the following tips (the so-called ‘dos’ and ‘don’ts’ will help in this.

• State your aims and goals: Think carefully about the things that you usually do. Put down the tasks and activities that are needed to be done every day, every week, and every month. But the most important is listing the goals that you would like to achieve in the end. Look at them attentively, analyze and set priorities. Then, rearrange the tasks in the list and add time limits and deadlines. It will give you a possibility to allot enough efforts for completing each task. Do not neglect minor tasks – they may seem not important at first but don’t procrastinate on them. 
• A good beginning makes a good ending: If your goals are set and time limits are established, it’s time to start the way to your goal. Be optimistic and believe in your success because, as the proverb says ‘Well begun is half done’. If you are not sure about the success, put aside the task for some time and start only when you are ready 100%. 
• Don’t forget about some extra time: If you know exactly how much it will take to complete the task, assign that amount of time. But if you are not sure, add more time in case of some problems or delays. Be flexible – if necessary, replace one task with another but still try to stick to the plan. Don’t forget about some unexpected things that can – and do – happen in life. Make allowance for such situations – leave some spare time in general. 
• Work done, have your fun: Life is not only work. Don’t forget about some pleasure and fun since they are needed to fill you with energy for new victories. If you only work, you will become stressful and annoyed, which will result in failures and broken deadlines.
• Stay focused: Well, if you have stated your goals, made a list of things to be done, walk towards your goals and don’t let anything or anybody make you leave this way. Stay concentrated! Don’t waste your valuable time on unimportant or time-eating activities.

So, I hope these tips will help you manage your time better and become winners!

Author Byline
Hi, my name’s Steward Copper and I am the owner of Project Management Insights. While working as a project coordinator and BA, I have tried almost all possible PM tools, BA instruments, collaboration programs, including tracker and task management software solutions. I use Comindware Tracker for my project management processes. Follow me on Linkedin.

6 Common Pitfalls to Avoid in Managing Distributed Project Teams

The following is a guest post from Andrew Filev of Wrike.

 According to a survey we ran with 1,000+ employees of various organizational levels, over 60% of them expect their work to go fully virtual in the next few years. Given that remote collaboration is becoming a more and more widespread trend, project managers need to quickly adapt their practices to the changing realities. So, what pitfalls are there to expect in managing distributed teams, and how can you avoid them?

Putting too much hope in self-organization leads to false expectations

Even though a virtual team generally enjoys some extra flexibility, it is deceiving to believe that it will function effectively without enough managerial control. Even more than co-located teams, distributed workers need common guidelines to get their efforts synchronized. For example, when and how to report on work progress, how to deliver results, which best practices and standards to adhere to in the process, etc. Simple and concise rules of work organization will help to get the team coordinated­ at any distance.

Reports instead of conversations lead to miscommunications

If the team’s communication is limited to exchanging tasks and reports, it’ll lead to at least two challenges. First of all, both the manager and the team will suffer from poor visibility into what’s really happening.  Second, this will make the atmosphere inside the team too formal. To avoid this, don’t stop talking! An ongoing conversation will keep everyone updated on the progress, help colleagues solve some questions together and also increase engagement. To add some face-to-face components, you might occasionally run a video-conference or even an offline meeting if there’s a chance.

Lacking the culture of sharing leads to frustration and low velocity

Transparency is one of the main challenges for remote teams. Often, workers get “siloed” with their own assignments, documents and reports, and all this info isn’t automatically accessible to their colleagues. Cloud technologies and social project collaboration software are great enablers in developing the habit of sharing within the team, so that work-related info isn’t isolated on personal PCs.

Not enough motivation leads to poor productivity and lack of satisfaction

Separated by distance, you can’t shake hands with every employee or pat high-achievers on the shoulder. But little things might matter. Express appreciation verbally, be that a thank-you note or a call. If your company’s policy allows, you can consider such acknowledgement options as flexible working hours, employer-paid leisure activities or personalized gifts.  

Making assignments too big leads to misalignment and poor visibility into progress

Without direct communication, there is higher risk of someone misunderstanding his goals. According to my experience, the key pain reliever in this case is assigning work in a more granular way. The remedy is simple: think big, but act small. With smaller assignments, a worker will understand them better, complete them faster and report easier. For the manager, in his turn, it will be easier to track progress both at bird-eye view and in detail.

Not believing in the efficiency of a distributed team leads to a self-fulfilling prophecy

To conclude, the biggest delusion of some project managers is being convinced that productivity stops at office walls. Yes, your employees do not gather daily at one location, but they are still a team that can be as synced, efficient and successful as a co-located one is. Don’t take the virtuality as a weakness. On the contrary – you have the opportunity to broaden your geographical, time and talent reach! You just need to find your own right mix of methods and tools to see the productivity of your distributed project team flourish.

Andrew Filev is the founder and CEO of Wrike, provider of popular project management software. He is a seasoned software entrepreneur, project and product manager, and advisor to several fast-growing ventures.

Refactoring

An interesting situation came up at work recently. I was leading a team that was reviewing an application that was developed about 18 months ago. There were some concerns around performance and scalability. The real question was, did this program need to be re-factored? How do you decide if/when it's time for refactoring?

One of the principles behind the Manifesto for Agile Software Development is Simplicity:

Simplicity--the art of maximizing the amount of work not done--is essential

In other words, keep it simple unless there's a current requirement to make it more complex. Don't try to design for some possible future requirement, design for what you know today...for what features are in the current iteration or release.

I've had architects that have struggled with this idea. They would argue that you need to come up with a comprehensive design up front. However, if the requirements aren't known completely (and when are they at the start of a project?) doing a full design will be challenging. I've seen organizations get caught up in analysis paralysis and have trouble getting anything built.

The key is to plan to the appropriate level of detail. At the beginning of a project there are a lot of unknowns, so a detailed design isn't practical. Focus on a design to get you through the first iteration, or maybe the first few iterations that make up a release. Know when you need to refactor.

What can change to require code to need refactoring. I can think of a couple situations;

• Change in requirements - Everything changes. As business needs change and evolve, the programs to support that business need to change as well.
• Change in technology - What technology are you using today that you weren't a year or two ago? Look at how popular devices like tables and smart phones have changed the the way people work and interact.

So what does this mean? The need for refactoring will always be there. I often advice clients that it's better to get a first release of an application to production as quick as possible, even if it's not perfect. You will start receiving some business benefits and it will give you better ideas on how to improve it.

Lean Project Management: How to Apply Lean Thinking in Your Next Project

This Guest Post is from Ian Needs of KeyedIn Solutions

You’ve almost certainly already heard of The Lean Startup by Eric Ries, a book that crushed business preconceptions by promoting a radically minimalist approach to new ventures.

Have you thought about how the principles of leanness can be applied to your project management? You should!

It isn’t all about ‘failing fast’. Lean project management boosts productivity and ROI by streamlining your project to focus on the aspects that have the greatest impact on success.

What Lean Project Management Means for You

Lean project management is the adoption of lean thinking in all areas of a project, from initiation right through to closure.

The aim is to deliver maximum value with minimum waste. In other words, you maximise your return on investment by investing as little as possible, while balancing this with optimal value to your business.

Adding lean thinking to your project management armoury helps you reach completion on time and on budget with minimum effort. To get you started, here are a few Lean Startup catchphrases translated into PM-speak:

“Eliminate Uncertainty”

Evaluate continuously, both to help you keep your project on-track and to know when it’s time to switch tracks entirely. Project management is an on-going process, and evaluation and feedback are vital for process evolution.

“Work Smarter, Not Harder”

Ask yourself first whether this project should be planned. A project whose rationale is shaky may not be worth your business’ resources. Second, ask whether what your need is already available – there’s no point reinventing the wheel if a solution exists that meets your project’s needs. Third, look at what elements you can automate to reduce waste.

“Develop a Minimum Viable Product”

For you, that’s a minimum viable project. Pilot your project on a very small scale, then measure and learn as you execute. By the time you initiate a larger-scale iteration of the project, you’ll already have collected a lot of valuable data to help you optimise the process.

“Validated Learning”

Incorporate empirical experiments into your project to validate your theories and test your assumptions. You can’t rely on an idea for project optimisation until you’ve validated it through the build-measure-learn process.

“Build – Measure – Learn”

For a PM, it’s execute-measure-learn. Never miss an opportunity to collect relevant, actionable data that can help you to laser-focus your project. Make sure that your plans include means and methods for making the most of this data once you’ve gathered it, too!

“Standardise”

In your projects, consistency of information, decision-making and communication are vital to smooth execution. Make sure everyone’s on the same page when it comes to outputs, and don’t forget the importance of standardising reward, too. Project culture and morale play a big part in the Lean Startup mentality for success.

“Pivot”

Sometimes, you have to abandon Plan A. This can be a stressful realisation, but don’t cling to your initial plans if the time for a course change has come. Plan B (or C, or D, or E) will give you a new horizon rather than leaving you stuck in a failing project.

If your projects have felt a bit bloated lately, try applying some of these lean ideas to clear the path. We’d all love to hear how it works for you!

About the author: Ian Needs works as Marketing Manager at KeyedIn Solutions. Find out about their comprehensive project management software package here.