What does project management mean to me?

A Brief History of Project ManagementProject management for me as with everyone else is all about managing projects.

Obviously how projects are managed and how you want to reach your goal depends on how you look at it.

Project management has always been a journey for me, where I have learned every single day from my work, from my team and from my mentors. It’s been more about people for me than managing work through tools.
    

    
When I started working in project management for the first time, I was part of a small service based IT organization in Chicago (US). I soon learned that people management skills were the most useful because it helped me create the connection with my clients and more trust I had from them, I could understand the expectation and always deliver more. I also knew that it also helped me work better with my offshore team, one I knew the local language and second I ensured everyone felt I was one of them. This allowed me to get to know of the real problems and not sugar coated facts when required. In return I could manage my requirement, delivery and clients better.

The way you treat your team always is the way team will treat you. When we worked under tight deadlines, team members took the initiative to stay back and get the work done. Not because they had to because they felt they were part of a bigger picture. Plus working in a small organization also means there is lesser capacity and always more work to be done. Handling situations specially tough ones, teach you a lot more because you are forced to think out of the box.

Agile project management which has gained much popularity talks so much about the transparency, efficiency, collaboration, cultivating team environments and adapting to the need- this is how I have always run my team and projects. And definitely this is the way I have learned from my mentors.

Project management for me is being successful and helping others become successful at what they are doing. It’s about understanding what makes everyone click and create amazing team dynamics where everyone grows and trusts each other.

It’s about taking the stress, so your team feels secure. It’s about creating an environment where there is lesser politics and more appreciation. It’s about supporting your team members no matter what. And it is about accepting the challenge and knowing that it won’t be easy and get up every morning and be happy to take up the role. It is about the stress, the tight schedule, the pressure to deliver, to handle problems, to be responsible, to be accountable for all failures, to work on weekends, to have sleepless nights, to smile and assure even when you are paranoid, to be there when all you want is to go home and still keep the role.

P.S. This post is published as part of a first ever project management related global blogging initiative to publish a post on a common theme at exactly the same time. Seventy four (74!) bloggers from Australia, Canada, Colombia, Denmark, France, Italy, Mexico, Netherlands, Poland, Portugal, Singapore, South Africa, Spain, UK and the USA have committed to make a blogging contribution and the fruit of their labour is now (literally NOW) available all over the web. The complete list of all participating blogs is found here ...so please go and check them out!

(Pic Courtesy)

PM Flashblog : Sept 25


The time is set to  25/09/2013 @ 01:00GMT and posts will be tagged on social media with #pmFlashBlog. To know more read Shim Marom's post here.

On September 25, 96 PM Bloggers from all over the world will participate in a flashblog.
You can see the teaser here

So, while you enjoy your weekend, I am traveling again tonight and the stress to pack over and over again has considerably reduced.

To learn about how to get into project management read my book Stepping into Project Management (Welcome to the #PMOT World). To connect with experienced Project Manager's from all over the world, get mentored or shadow for a day see the SIPM Community.

7 Tips: When travelling for work



Travelling can be fun unless you are doing it way too much.

I still love it and the challenges it brings with it, over the past few months I have learnt the art of  packing mostly over terrible mistakes.

  • Always pack in your own shampoo- The hotel shampoo might leave your hair so limp that you wished you had your own.
  • Always have an extra pair of clothes in your handbag/backpack- I keep one in my laptop backpack just in case my luggage doesn't arrive. 
  • Travel Light- I carried more than I should initially, now I just pack right most of the time.
  • Keep a list- It helps every time.
  • Be comfortable- I carry one thing with me that will make me comfortable and keep me relaxed: a magazine, iPod, a good book.
  • Try local cuisine- This is my favorite part of travelling, I might not get the time to try out sight seeing always but at least I get to try the food.
  • Learn everyday- There's so much to learn by just observing people or while travelling. We get used to the same set of people so much that a change while travelling gives us a better opportunity to learn when we travel.
So, while I'm leaving for the airport in the next 30 minutes- I hope you get the chance to travel and say yes to it!

How should teams be build?

When an actor comes to me and wants to discuss his character, I say, “It’s in the script.” If he says, “But what’s my motivation?” I say, “Your salary.”
                                                 —Alfred Hitchcock, filmmaker (1899–1980)

Jim Collins talks about getting the right people in the bus in his book “Good to Great”. And we all agree- but how do you decide who are the right people?

Hiring happens based on the core competency, but when you put them as part of the team, how do you know they will work out?

Does team dynamics matter to you or your organization? Do you think it changes the quality of delivery?

The common failings for any team at organization level usually comes down to:
·       Develop empowered people working together to serve the best interests of the organization, and
·       Create an environment in which every employee contributes all of their talents and skills to the success of organizational goals.

To ensure we get individual players be and feel part of the team- is there a way to create teams at the first place differently? Like do you think, if teams are created based on their compatibility or interest, they will perform better OR do you feel any team if mentored and trained in team/organization culture will perform at their highest level?

To think about creating the right team, I think we should first think why teams fail at the first place? Why do teams not perform the way they should be? Is it a bad apple? Is it lack of proper management and setting the expectations? Is it freedom without no boundaries and when things go wrong, blame the team? Here are 20 mistakes that employers make.

Are we aligning people with their interest and what they want to do or do we just not hear what they have to say and push them into any role and any teams?

The hedgehog concept talks about looking into 3 aspects before putting the right people in the right role
By considering:
  • What are you passionate about?
  • What can you best in the world at?
  • What drives your economic engine?
This definitely brings out the best in individuals but how do we ensure the best is brought out at team levels also?  What if you got the right person in the right role and then had a bunch of laggards as team mates. Do you think we have set the right environment for him/her to grow and contribute to the best of ability?

How does your organization formulate teams? What do you fee is the right way to do it? 

(Pic Courtesy: Google Images)

Interview with Ellen Grove

We are happy to have he opportunity to interview Ellen Grove, who helps teams do better work by coaching them to create the circumstances in which they can work most productively. Her Agile coaching practice with agilepartnership.com is founded in over 15 years’ experience leading software development and implementation teams in global enterprise, a passion for exploratory software testing and user-centered design, and a background in community organization. Ellen presents frequently at Agile conferences, most recently: San Francisco Agile 2012,Agile Day NYC 2012, Agile Tour Montreal & Ottawa 2012, Play4Agile2013 (Germany) and Agile Games 2013 (Boston).  She is the Scaling Agile Adoption theme chair for Agile India 2014. 


How did you begin in agile coaching/consulting?

I got my start as an agile coach while I worked for a large telecom company. My background is as a software tester, though I've done a little bit of everything except coding along the way.  My team had begun as a startup, which had been acquired by the large company but maintained the startup mentality of doing it all ourselves and trying to get things done with a minimum of process.  The company decided that they needed to introduce a standardized process for software development across the entire company; my team looked at the proposed process and realized we'd need to double the size of the team and the length of our release cycles just to handle the process overhead, which was obviously not acceptable.  

We decided that we would need to counter-propose an approach that would demonstrate some discipline in the process yet give us the flexibility we needed to do things very quickly.  Until then, we'd been playing with some Agile ideas informally, but hadn't really made an effort to work intentionally in an Agile way.  

This is when we got serious about Agile.  After arranging for myself, my boss and his boss to attend Scrum training,  I helped to organize and deliver Agile training for all the teams involved on the project: there were three teams involved, spread over 3 countries and a 10-hour time difference, as well as an external vendor who was supplying a vital component.  We were working in 1 week iterations (integrating the work of 4 teams) and learning a lot as we went along. I was playing many roles - leading the testing function, acting as Scrum Master for one team, and serving as an internal Agile coach to the larger project team.  I was also involved with the company's process team establishing an Agile alternative to the big universal process they were trying to introduce. It was crazy, but quite a lot of fun while it lasted.

When that role ended, my next gig was as a project lead on a non-Agile global network transformation project, very complicated and complex and risk.  What I learned from that experience was that I really only wanted to work on Agile projects, since Agile approaches offer some of the simplest ways to manage risk and complexity.

In a small company with less then 200 people following Agile, do you think a project managers role is as important and would be beneficial. Why?

Interestingly, in the large telecom situation there was never much attention paid to project managers, even though we had one on our team all along (even when we were still operating as a startup).  The PM was the person who updated Gantt charts, counted things and went to boring meetings that none of the rest of us were interested in.  It was quite a surprise for me to start consulting in other organizations where the Project Manager was effectively the leader of the project.

I think that many of the functions of project management are critical, but on a smaller team/project the important elements of the function can be built into the team's work and there's often no need for a designated project manager. Where I've seen real value in a PM role is in larger organizations where the PM acts as an interface (and shield!) between the development team and other functions in the company, allowing the Scrum Master (if the team is using Scrum) to focus on supporting the team's day-to-day activities and leaving the team to coordinate its work internally.  It's often very hard for people who are accustomed to a traditional PM role to make that jump and let the team have space for self-organization. 

Tell us a little more about what you do as a LEGO Serious Play facilitator.

I love doing LEGO Serious Play - I wish I could spend all my time running LSP workshops!  LEGO Serious Play is like play therapy for business.  It's a very simple, structured process that enables people to have really important conversations about how they're working as team or to share ideas about the work they're doing in a way that is designed to help them get to the heart of the conversation very quickly.  

How an LSP session works : the facilitator asks a question, the participants build a model to answer the question in a very short period of time, and then each person at the table shares their story about the model with the others. This process is repeated a few times to build up a shared understanding of the subject at hand that incorporates the viewpoints of everyone taking part. A longer workshop may involve fitting the individual models together in an integrated landscape to really create a shared view of what the aims of the group are. 

It's simple, but incredibly powerful.  Because people are using their hands as well as their brains, unexpected ideas emerge.  Time-boxing the builds forces a focus on the most important ideas.  And seeing the ideas take shape on the table results in a different kind of understanding about how the pieces fit together.  I use LSP for everything from team building sessions at the start of a project, to strategic visioning and planning, to retrospectives.  

I've written a bit on my blog about how LEGO Serious Play works.   I tend to overuse the word "magic" to describe the results of LSP, but every single time I run a session I'm blown away by what ends up on the table.  People are often very skeptical before they've used LSP to do work because it seems silly and not serious, but once they've taken part in an LSP session they realize how incredibly powerful it is as a tool for helping people to express what's in their heads and their hearts.

When working with organizations how you do come up with a strategy?

My Agile coaching strategy is fairly simple:  1) Help the organization figure out what they're really trying to accomplish, and then 2) help them find ways to get there.   This sounds easy but usually is not, especially in larger organizations where there is often ambiguity and conflict in what the real goals actually are.  With small teams/companies, there's usually a clear set of desired outcomes driving the team ('Make customers happy so that we make money and stay in business').  With larger organizations, especially in the public sector, it's often much more complicated to understand what the actual goals and desired outcomes are. "Get the project done" is a fairly meaningless goal unless you understand what the real value to be delivered through the project is and who you're delivering to, but large public sector projects often fail to communicate either of those things to the people who are doing the implementation work - the message conveyed to the team is usually "Here's the requirements, just get it done!".  It's very hard to transition to an Agile way of working in those kinds of organizations.


What are the 3 things you would suggest to all Agile project managers? 

Focus on the value being delivered through the work, not the meeting the expectations of the plan. Inexperienced PMs sometimes lose sight of this and confuse "successful delivery of project artifacts" with "a successful project".    It doesn't matter if you deliver on time and on budget if the end result doesn't please the people it's meant for. 

Trust your team to do the right things (and tailor your behavior accordingly). People tend to live up to what's expected of them, and if you want to encourage responsibility and accountability in your colleagues, you need to treat them as responsible, accountable individuals with good intentions and good judgment. Most people want to do great work - and if they don't, taking a command-and-control approach to managing their work won't result in happiness for anyone. If they do want to do great work, a controlling approach is just going to get in their way.

Make it safe for the team to fail. If you don't want the bigger effort to be a failure, you need to help create a culture (at least within the team) where it's OK for people to make mistakes and to ask for help when they need it.  I've seen too many big problems that were caused by smaller problems being ignored or hidden because team members weren't comfortable being open when things went wrong.  I'm a big fan of the "Failure Bow", because it's so much better in the long run to handle failures well instead of blaming-and-shaming so that we can learn from mistakes.

Thank you Ellen.


(Pic Courtesy: Ellen Grove)