Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Tag Archives: Microsoft

Project Managers … visionary leaders or shepherds?

I was having an interesting philosophical discussion with some peers. Opinions were expressed on how project managers need to be visionary leaders. Most project management courses do not cover much on the art of leadership. I tend to think if you have to teach leadership, then it is already a lost cause. Although leaders are not necessarily born, they see an opportunity and make their mark. Those that wait to be taught or asked by definition are not suitable leaders. But this was an interesting discussion. Do project managers need to be visionary leaders?

Let us look at the traits for leaders. If you look at any leader, what is the one thing you remember about them? I am not old enough to remember many contemporary political leaders – Gandhi, Churchill etc. The one that I do remember is Mandela. These people have a vision of the future, have the courage to express it when it may not be the orthodoxy and have the ability to project their vision even through difficult times. It is the same in business. Steve Jobs and Bill Gates did not get Apple and Microsoft to where these companies are on a bed of roses. But neither the political or business leaders actually organized the mass rallies or the next version of the software.

The case of business leaders is even more interesting. The reason they are the leaders is because they see a gap in the market and have ideas to fill it. They want to be the first to market. They do not always appreciate what it would take to get there. They are also wired to see many possibilities and constantly thinking about the next big thing. They utilize people with the right knowledge to analyze which of these have wings and will fly, and which ones are likely to sink. The ones that fly then need to be managed to successful delivery.

Is project management the same? Well … part of it. The emphasis on vision and leadership is more appropriate at the top management level of the organization and even maybe at program or portfolio management level. Once these are defined into projects, the emphasis on leadership is different. I think of that leadership more akin to a young military officer. If you have seen the mini series Band of Brothers, I say Major Winters is the project manager. The role itself comes with an expected level of respect. But it is not given by default. You have to earn it by your track record.

Once you win over people by showing your aptitude they are willing to go beyond the call of duty for you. This is also a type of leadership, but different to the one that one that we had been talking about earlier. The goal is to win the individual battle, rather than focus on the overall war. He takes lessons from his team’s engagement and those that he sees of the other units. He marshals his resources to achieve his objectives. If he worries more about how the battalion is running its affairs, his troops will be left to fend for themselves. This is the type of leadership that can be applied to project management.

In project management, you provide leadership by understanding the context of the project and good communication, recognizing efforts and ensuring single purpose. When you have achieved trust of your project team, you have successfully become a leader.

Major Image Credit: PhotoBucket

Have Project Management tools kept pace with time?

I have recently been looking at optimising the way we manage projects. One thing this has led me to think is whether some of the project management tools have kept pace with the way people work today. I am not looking to re-invent the wheel. Neither am I wanting to be lazy. I am after a way to effectively manage delivery by utilising all my resources to the best of their capability.

Projects have been undertaken since humans first realised they could organise themselves into a unit to achieve mighty things. Even before the discipline of project management was a recognised one, we managed to build the pyramids, the Great Wall and the Taj Mahal to name a few. Does that mean it is a profession that exists for no purpose? That is not true. Many of these projects were run by autocratic rulers who had no regard for human life. All three of the projects I mentioned cost the lives of thousands of workers. Fear for life was a successful motivator even as recently as a few decades ago in the communist Soviet Union.

As we have realised fear alone cannot achieve good outcomes, we have put in effort into devising methods to manage projects in a predictable manner. We have many methodologies – most of them very mature. But it seems applications have not matured to the same extent that methodologies have. It still amazes me how many organisations still manage projects by using Microsoft Excel. The next most widely used application I have seen is Microsoft Project. That however has seen no useful upgrade between the mid 1990s, when it first came out and 2010.

Microsoft has realised the folly of that approach and has been concentrating on their enterprise offering of Project Server. I have previously posted about using Project Server and utilising it to identify resource gaps. Having used it for a few years, I have come to the conclusion that it takes considerable effort to keep updated. Unless you have a PMO with enough resources to stay on it, it is nearly impossible to use effectively. Interestingly, LiquidPlanner has taken a different tack to managing projects by accommodating uncertainty through a high and low effort estimate. That is a very useful method if one is using it to manage product development. However, I was unable to find a way to use any sort of baseline that would allow me to track how the overall project is going compared to the original plan.

I have been trying to think what would make a project management tool stand out from the rest. I want to get away from managing in a hierarchical manner Project Managers have traditionally operated in. I want to ensure that the people working in projects I manage have the ability to raise risks and issues with a minimum of administration effort. I want to know the status of projects as close to real time as possible, but not have to chase up for updates continuously. That only serves to annoy technical people, and is a complete waste of my time.

This is the age of social media. People are used to collaborating in all aspects of their life. Being connected is not a bad thing. The project management discipline can benefit from this constant connectivity. If done well, it can provide early visibility of risks and issues, provide a platform to share ideas, sharing knowledge and lessons learned. Having a mobile presence is a must to achieve this. Some of the Agile product management tools have done well in this respect. Another complicated factor is the need to integrate the output from this with billing or ERP systems used by the organisation – in our case SAP Business One.

My search is yielding mixed success. I have been looking closely at two products – WorkFlowMax and AtTask. Both seem to fulfill most of what I am after. I am keen to hear from you if you have tried something similar. What has your experience been? Have you found any products to be good in the areas I am looking for?

How do I manage a distributed team?

As the world becomes smaller due to more efficient communication, distributed teams are becoming quite common. If you ring a customer service line in any country, the odds are you will end up being serviced by someone in Manila. Your latest Microsoft software was most likely developed in Bangalore. I have been managing projects with teams and clients  scattered in different parts of the country, and in some cases spanning multiple continents. I have been thinking about some of the challenges I face and how best to overcome them.

The biggest and most obvious challenge faced in managing distributed teams is the fact that you are not where they are. Even with all the new technologies, talking face to face remains the best form f communication. There are many forms of communications in projects – the truths, the half truths and the outright guesses. When you are managing the deliverables, you need to be on top of what is what. While this is not an insurmountable obstacle, it is a rather expensive one to mitigate. People work best with people they have known personally. They are more likely to be upfront with realities, than someone they find hard to relate with.

Working in different time zones also amplifies the problem. As an example, I work out of New Zealand and work with people in the west coast of the United States. During the southern hemisphere summer, it is reasonably workable, with abou 5 hours overlap. However, we lose a day. So we get about 20 hours during the week. In winter, during the Pacific Daylight Time, the overlap is as little as 12 hours. Our other base is in India, which starts work as we are leaving for the day.

Work cultures vary in different parts of the world. That plays a significant part in bringing a team together. New Zealand has a very relaxed working environment and an excellent work life balance. This is not to say, Kiwis are lazy by any nature. A lot of our innovation comes from this part of the world. I find Americans are much more intense with their work and put in significantly longer hours. Consequently there is always possibility of conflict if the teams perceive each other to be too pushy or too relaxed. Work cultures also vary in how people communicate bad news (or how they do not). While you do not want bad news in projects, if it does  pay to get it early.

If you are indeed managing people from all the different locations, the likelihood is you are not their direct line manager. They are each likely to have their own line managers to keep happy. This in itself is not uncommon in a project scenario. Temporary assignments from operational teams is a routine occurrence. It is quite different when you are not there to ensure the story you get is the reality, rather than the party line.

You can alter your usual working hours to accommodate additional collaboration between the teams. You can utilize advanced telecommunications to give a feeling of co-location and one team culture. These are all good measures, but intermediate ones. The more the teams are isolated, your picture will be less realistic and you will struggle to enforce uniform processes across the teams. The only way to bridge that gap is to ensure regular face time.

If it s important enough to have distributed teams, it is important enough to ensure effective management.

Handling emotions in projects

Most people get emotionally attached to any creative work. While there is considerable element of science in breaking problems down, in software development, there is an equally significant element of creativity in resolving complex requirements. This is further heightened if you get to design the solution from ground up. I was part of such a solution – my role included business analysis and project management, but no development. However, I still felt significant ownership of the application, as I had contributed to ultimately what was delivered to the client and it had won awards in geospatial and port domains.

We had built the application with a view to making it modular enough to take individual functionality off and build another solution without having to start from first principles. Our lead developer had put it this way – a box of Legos – build what you will with it. We had tried to build this level of re-usability for some time and had finally looked like we had made a breakthrough. We were really excited with the prospect and the awards seemed a perfect vindication of our approach.

In a similar timeline our company became re-seller for a similar product. That product had a significantly larger development team behind it. As we provide implementation and customization on that product, it is becoming increasingly obvious that our original development would eventually be swallowed up by this product. One of the weaknesses of our development was a lack of configuration utility – which the new product addresses quite elegantly.

We are currently undertaking an exercise to upgrade the existing application to the latest Silverlight design patterns. We have had to think long and hard about whether that is indeed something that makes sense. What we have now decided is to produce a migration plan that would eventually merge the two together – hopefully leveraging best of both. This relies on design patterns of both being compatible. We’re in the process of undertaking a study to establish whether that is a realistic option.

From a business and technical point of view this makes good sense. We are simply not large enough sustain both and do justice to either. However, when you have your blood, sweat and tears invested in something, it is hard to let go. Mine was less than the developers … and it was no easier.

Using Project Server 2010 with MS Project

I had previously posted an article about forecasting resource requirements using MS Project Server 2010. It has since dawned on me that on of the real difficult issues I faced in my early days in Project Server 2010 is the challenge of figuring out how to get it to work with MS Project desktop products. Well … following is how you do it. Read more of this post

%d bloggers like this: