Welcome to WordPress. This is your first post. Edit or delete it, then start writing!
I have recently been spending some time working on a large IT programme to upgrade a core system involving several hundred developers and several different vendors. Dealing with a large number of Programme/Project Management (PM) artefacts manually is very time consuming, labour intensive and at times, error prone. It is obvious that PM tools have fallen behind the times and could do with being modernised to improve its user experience and automation capability. We only need to look at the DevOps arena to see how the development tools have evolved in that space to improve workflow and automation to support accelerated development and continuous delivery.
The DevOps community has only been around a few years, yet it has evolved tremendously due to its large community of users and the large base of open source software to allow the tools to inter- operate with each other. This approach allows single sources of truth to be synchronised to create a unified system that is highly automated to support end to end development workflow.
The speed of software development achieved using DevOps creates a challenge for PM; how can we keep up with the development pace using disjointed PM tools that require a high degree of manual intervention to reconcile the project data manually? Is it time that we create a PmOps arena so that we can borrow the DevOps concept and bring that into the PM space?
PmOps, short for Project Management Operations, would support PM by using different tools that allow single sources of truth to be synchronised to create a unified system that is highly automated to support end to end PM workflow. Tools such as Active Risk Management (ARM) could be use to scan project schedule for missing dependencies, resources and risk ratings based on statistical measures using 3-point estimations . Timesheet, Finance and Contract Databases could also be part the PmOps arena to automate the generation of project spending, invoice payments and forecasting.
The purpose of this blog is to get this discussion started with Project Professionals and Practitioners. What should PmOps look like? What are the critical tools that should be included in a minimum viable product for PmOps? Please take the time to leave a comment on this blog to help steer the direction of PmOps to help solve your PM pain points.