In this second part of a four part series we are going to look at Quadrant 2 in the diagram, where the project maturity process level s are high and it detracts from the contract negotiation process.
The ability to collaborate as a project team is the key to it’s success. As the Project Manager you need to ensure that collaboration across the team is easy and working.
For the past four months I have been using a collaboration tool for my own projects. There are a number of these tools available in the market, each with similar and different features.
I’m going to talk about my own personal experiences of using Xtrant so that you gain some idea of the value that I see in using this sort of tool.
I want to suggest that project failure is relative to PM skill level. Of the research that I have looked at project failure can generally be categorised under a set of key areas. If you identify with any of these triggers then I suggest to strongly consider your skill levels.
In this first part of a four part series I will investigate and discuss how project management process maturity within an organisation might impact on contract negotiations.
In each part I discuss one of the four quadrants in the diagram above including both perspectives from the procuring organisation as well as the supplier in the negotiation process, as there are different impacts depending on which perspective you are.
In order to build a strong ERP business case, robust analysis is required. I suggest that the following areas be fully investigated as part of building your business case:-
People with technical backgrounds don’t make good project managers (in my opinion). Why? Because they are usually way too focused on the technical aspects of the situation to be really ‘managing’ the total project or program.
After watching sporting teams playing in the finals (and ultimately the Grand Final) I realised that there is a strong connection between these high performing teams and project teams that perform well and succeed. How you may ask?
I’ve spoken before about what I see as the really strong value in creating what I call a ‘One Project Team culture‘ and a discussion that I had today reinforced my views on this principle.
Many projects fail, because there is too much tension around ‘who owns the system’ (business or IT); ‘they don’t deliver’ (and ‘they’ usually refers to the IT team/department; ‘you wanted too much’ (which is IT talking about the business); ‘you didn’t let us do our job’ (again IT talking about the business); ‘we know what’s best’ (IT talking TO the business).
Detailed business requirements are as valuable as a well written business case. I say this because detailed business requirements provide clarity, just as a well written business case does.
What therefore does it take to create detailed business requirements? Here are my top five tips:
Whilst, as a Project Manager I prefer to manage a project my own way there is value in visiting the ‘Lessons Learned’ logs of previous projects run within the organisation to see where common problems or risk areas lie.
In the context of IT projects there will be very valuable lessons that will have been learned from other IT projects that have already been carried out by the organisation in areas such as data migration or system configuration, or business engagement, for example.. If this is the case, then doesn’t it make logical sense to tap into that wealth of knowledge and use it to better set up and manage your project?
Here’s a different form of negotiating.. Don’t accept ‘No’ as an answer, when you need something for your project. Why do I say that?
As a Project Manager I am being paid to ensure that I deliver this project for my Business Owner, to the best of my ability, on time, on budget and within scope. And yes, those are the standard project success factors. We can talk about other just as important things to measure success by, but I will leave that for another post.