Business project vs IT project. This is the debate that never wins me friends, because the people that I debate this with have a strong sense that Information Technology (I.T.) is the world and therefore how dare I have a different point of view.
If you are like me you will have been involved in a large number of projects where data is involved and most times there have been issues on the project. In most IT projects the reason for the project is a better way to manage customer data is needed.
In this article ‘22 tips for better data science‘ I found that I connected with some of the tips more than others. Here are the ones that jumped out to me:
For this post I bring you useful resources that I have found today. Each article has great insights that may help you be a better Project Manager. They may help you answer some questions or fill a knowledge gap that you have. They are an interesting mix of articles. I have chosen them because each one provides some useful information that I would like to have had in my early days as a PM.
When is a project not a project, when it’s a Business As Usual activity.
I was involved in a very interesting situation in the past month whilst working as the Project Manager and Change Manager on an initiative which I would call BAU. It felt like being caught in the BAU versus project trap, an age old argument that occurs in most organisations.
I work near some really switched on project finance team members who know their stuff. In the last couple of days we’ve been having a great on-going discussion about ROI (Return On Investment). Of course it has gone hand in hand with discussions around benefits realisation, but that content is for another blog post. What we’ve decided is that good ROI doesn’t mean project success.
Who ever said an EDRMS implementation needs to be a difficult task?
Elise Stephens from Fix My Project Chaos and I caught up to talk about ‘How to fall in love with your EDRMS implementation’, or in other words the key tips for a successful EDRMS implementation. We had fun discussing the similarities between EDRMS implementations and relationships.
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.
In my opinion most people don’t really understand what ‘managing’ a project is actually about.
I have seen many project managers who do everything other than actually ‘manage’ what needs to be done in order to deliver the project. And in seeing this occur I also see that the project is usually flailing, falling behind, and there are problems delivering.
So, what does it actually mean to ‘manage’ when we talk in terms of a project.
Do you see yourself as a ‘Project Manager’ or a ‘Change Manager’ or a ‘Project Manager managing change’?
It is interesting considering the context of these titles. Project Managers are seen as people who manage projects, whilst Change Managers are seen as people who manage change related to projects, or as the outcome of projects. But on a number of projects there is only the Project Manager managing change.
A Project Manager should be able to handle anything and everything that happens in line with their role of managing the delivery of a project. They shouldn’t need support or help, as they have the skills and resources to enable them to do the job.
What do you think of my statement?
This week I have been focused on developing support models for two different projects so felt it worthwhile discussing how to develop a support model that really does support the customer or end user.
Managing a project is easy, right? Most Project Managers, would answer No to that question. I thought that I would provide you with five easy ways to not manage a project in case you needed some help.
Never underestimate the value of early stakeholder engagement to a project.
I realised this week how easy it is to overwork, under work, go off on the wrong tangent, not do what is really needed etc., in delivering a project just because you don’t engage the right stakeholders early enough in your project.