Project Management in Practice

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

Tag Archives: Project management

Are the days of MS Project numbered?


Using MS Project is a bit of a right of passage for most people that have done project management in an enterprise scale. While many have grizzled and grumbled about the application, for a long time it was really the only one that would allow you to do what you needed to get done. What made it worse was between 1998 and 2010, there had been little new in terms of functionality and user interface that made life easy. With 2010 (and 2013) with the development of Project Server, Microsoft has added a few useful functionality.

A lot of web development folk had already deserted MS Project (or never used to begin with). The likes of Basecamp and Jira had been very popular. But there remains a good proportion of traditional PMOs that will require you to provide information and updates in MS Project format. So we could never really get rid of it.

Gantter

Also gone are the days when everyone in the enterprise uses a bog standard OS and store things in a common location on the network. People are more mobile. BYOD is pervasive in most organisations. Many use Mac laptops, iOS or Android devices while on the move. If you subscribe to Office 365 on a Mac, you cannnot event get MS Project. While Microsoft addressed some issues with Project Server, many of its Project Web Access functionality didn’t work properly outside IE.

I recently came across Gantter from smartapps.com. I am pretty impressed by what I see. The main Gantt view pretty much looks like MS Project. Rather than taking a lot of MS project functionality, they look to have taken the most used ones – tasks, resources, calendars, and baselines. It has even added one thing that plagues most Project Managers (and ends up getting managed in spreadsheets) – Risks!

Gantter can be integrated with Google Drive or Apps and allows you to have real time editing and chat with other Google users. It also allows you to save your projects into your OneDrive or DropBox storage. It can load projects from MS Project and also export to that format. There are plenty of default templates to get you going, or you can create your own. The best part is … it’s free. No longer do you have to pay exorbitant fees for MS Project.

I’ve only just started using Gantter. So final judgement is still pending. However, based on what I can see to date, MS Project’s days may finally be numbered. Even if you’re forced to report in that format by your customers.

Useful Project Management Presentations


In this post I have attached some presentations I have done over the years on project management and related topics. As I was looking at my SlideShare uploads, it occurred to me that these can be quite handy for others too. Hopefully it is of benefit to the readers of this blog.

This presentation is on the topic of managed services, presented at the International Esri Distributor Summit in San Diego, CA in July 2013.

The following presentations are two flavours, first one delivered to the PRINCE2 User Group in Wellington regarding benefits of using multiple ideas together. Second is a presentation to internal PMO regarding improvements to existing processes in project management.

The final presentation is one given at an IT conference in Wellington, New Zealand based on experience of enterprise software implementation at a major port in the west coast of the United States.

Enhanced by Zemanta

When Project Managers can be dangerous


When project managers can be dangerousAs Project Managers we are in the business of control and order. We are placed in a position of trust to achieve the desired outcomes. Most actions we take usually reflect this. The other day I was nearly caught out by something and was rescued by my architect. The worst consequence would have been some lost time in discussion. That made me think, can project managers be dangerous on projects sometimes? I think yes. Here are my top 5.

1. Know too much

This was my problem. Having come from a technical background, I thought I knew something when I only knew part of it. I enjoy keeping in touch with technology and am usually good at knowing when to shut up and let the experts lead. Usually this technical knowledge gives me a good insight to ask questions on approach, probe for weakness. On this particular occasion I could have sent the discussion on a tangent. A position of authority usually brings with it a level of credibility. If you overreach your knowledge there is a risk that people will not challenge it. Project Managers must know their limits. It always pays to have in your team that are willing to ask questions and willing to correct you if you are in the wrong.

2. Know not enough

It may sound like I am trying to have my cake and eat it too. Just as overreaching your knowledge can be problematic, so can be being totally oblivious to problems. Project Management text books will have you believe you need no content knowledge when managing projects. While that can be true, it can only succeed when you have able technical expertise on tap. That is not always available unless the project is of a certain size. The best way to build credibility with your team is to demonstrate you know what success looks like. You can only do that with some content background or the help of a very able lieutenant.

3. Project going too well

Things going too well early in a project is sometimes is just about the worst thing that can happen. It may sound counter intuitive. I have too many occasions where Project Managers get lazy and forget to pay attention to the important things – recording decisions, deviations from scope, paying attention to risks etc. Projects are risky endeavours. Experience tells us that not everything will go to plan during the project. If you have grown lazy with a good start, you can be guaranteed difficulty ahead when the worm turns. When Fred Brooks Jr, the father of IBM 360 was asked how one of his projects got to be twelve months late he responded … one day at a time.

4. Becoming rigid

There is a tendency sometimes to manage by actions rather than outcomes. Our goal is not to deliver the actions in the plan, but the outcome in the business case. Project plans must be living plans. There will often be the need to adjust course to get the best outcome. Sticking to prearranged plans will give you a great Gantt chart with beautiful baselines. Sometimes you can deliver to exact plans and deliver no benefits to your customer. Your plan must have some slack, so as to not fall over at the first risk. Allow yourself the flexibility of not using 100% allocation. Expect some sickness, administrative times, training needs for project team members. Avoid having to hand a change notice every day. Project Managers must understand the difference between being in the right and getting the right outcome.

5. Spreading chaos

There will always be an element of pressure on the Project Manager. We get paid to navigate the team through uncertainties. Sometimes progress is not what we hope for. From time to time we face unrealistic expectations from our own management or customers. There are various ways to handle that pressure. The one thing you must avoid is spreading that feeling of pressure to the project team. Even in most difficult cases if shield your team from some of the external pressures you have a reasonable chance to salvage something out of the situation. If you let your pressures on to your team, chaos will ensue.

I’m sure there are many other ways we can compromise a project. I would be keen to hear your thoughts.

Image Credit: http://www.techweekeurope.co.uk

Is ‘No Estimates’ for real?


No Estimates is a concept that I had not come across until very recently. The basic premise of No Estimates is there is significant inaccuracy in software development estimates. Even when you spend a lot of time estimating, it is still not necessarily accurate enough to give you an exact picture. Therefore, the time spent estimating does not give you a reward for that effort. Proponents of No Estimates argue you may as well spend that time and effort into understanding what the most important feature is to the user and concentrate on getting that delivered well. Once delivered, you concentrate on the next most import feature and so on.

Is No Estimation for real

When I first read about it, my initial reaction was it was like throwing the baby out with the bath water. Just because we are not as accurate at estimating simply giving it up seemed like lunacy. On reflection however, I can see it being useful for in-house teams that are supporting a business application. There the organisation has already seen value in continuous improvement and has accepted the software developers as part of the package to deliver the business outcome. You can concentrate on small measurable improvements to the application as directed by business. The users in this case are well versed with the application and are able to explain the desired improvement. Interestingly enough, in my experience this type of development is comparatively easier to estimate than others.

I also had a thought that product development teams may be able to use this in some manner. The rationale was they have quite a bit of control in terms of what they can cut out of scope if something turns out to be more difficult than initially perceived. However, the tradeoffs they make are not necessarily linear. There is usually not comparison that you can unilaterally say is feature A versus feature B. Feature A may very well be more important, only if it is likely to  be no more than 20% more in cost. No Estimates as a concept is not well geared to help in this scenario.

Even in scenarios where No Estimate is a reasonable course, I see significant risk of what I call ‘design blinkers’ – only taking into account the immediate requirement(s), rather than an overall view to limit rework. Design blinkers happen in all form of software development. This is because you can only design for your known scope. By limiting your thinking horizon to the next most important feature, you are in effect likely to encourage less holistic design.

From the reading I’ve done so far, it appears there is a level of misunderstanding in what estimates are used for in projects. There are no perfect estimates – projects are by nature risky. You can only ever be expected to deliver estimates with complete accuracy early on. They should get progressively accurate as you go through the various phases of the project. Initial estimates to judge whether the client has the cost appetiate to even embark on the journey, then further refining to understand whether your organisation can execute the project safely with a level of profit. These estimates will be less accurate than your feature level estimates, that you will be building up when the project goes into execution. In most cases you use multiple methods of estimating than simply a combination of all the features – previous track record, comparative scale with other similar projects and some level of feature based estimation.

In my view there will be very few situations where you can get away with doing no estimates and be able to make the decisions you or your customer needs to make. The answer is not to avoid estimating, but estimate at the level of accuracy that is required to make the decisions. Never estimate $X or hours Y. Always clearly state estimates with their level of accuracy i.e., $A to B or hours Y to Z.

Image Credit: Dilbert (Scott Adams)

How much financial knowledge do Project Managers need?


I attended a training seminar the other day on finance and accounting for non financial managers. It was an interesting training course. If you consider the constraints within which project managers must work to, one is financial. The last time I studied anything remotely close was accounting 101 during the first year of my under graduate degree some 17 years ago.

How much financial knowledge to Project Managers need

The course was run by Victoria University Professional and Executive Development school. Not being a student of accounting and finance, the seminar title seemed like exactly something that I’d be able to use in my project management role. As the course outline was being set out, I realised this was probably the wrong form of accounting for me. The primary focus was on accounting concepts and how to understand company accounts and performance. It appears management accounting is what I should’ve been looking into for making decisions based on numbers.

While I didn’t totally achieve what I wanted to in terms of outcome, it wasn’t a total waste of time either. We focused on importance of cash and return on investment based on various capitalisation models. I had never thought to consider projects, or even business cases along those lines. It is a very useful knowledge to have when considering the straight ROI figures. I will be much wiser to attempts at manipulation along those lines.

This all made me think, how much financial knowledge o you really need to manage projects effectively? Projects are usually incurring expense until such time it is transitioned into the business. Usually project managers will not be responsible for the realisation of he benefits. That means unlike accounting, all the numbers are in one direction. That is why most project managers will be able to get away with limited or no accounting and finance knowledge, as long as te are reasonably good with numbers.

This all changes when the project manger becomes responsible for both generating income and controlling expenses, which is the case in supplier environments. I have a set number of resources that I can utilise for various projects. How I use these resources not only determines success, but also income for my team. In strict sense this is more akin to portfolio management, rather than project management. In this scenario, I found the focus on importance of cashflow and various funding models was very useful.

If you are running a programme that is designed to deliver a financial benefit, I can see a very practical application in terms of analysing if you’re meeting the desired profit targets. Similarly, if your benefits can be quantified in terms of monetary value, then understanding accounting and finance is very useful. However, in general I haven’t found the lack of understanding in this area hasn’t necessarily made life any more difficult, as I am comfortable with numbers in general.

My role involves more than simply managing projects. It also includes forecasting of revenues, participating in the sales process and contributing to strategy among others. I still think understanding management accounting may be very useful. I will probably look to get some more professional development in that area. Again, those in my view are more portfolio management in nature, rather than project management.

What has your experience been? Am I totally off track?

Image Credit: best-financemanager.com

%d bloggers like this: