Personalized Community is here!
Quickly customize your community to find the content you seek.
Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2021 Release Wave 2Discover the latest updates and new features releasing from October 2021 through March 2022.
2021 release wave 2 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
“Software projects are no different from other projects”.
This statement is being repeated over and over at project management courses and seminars, even endorsed in books.
It’s true that software (and ERP implementation, as a subset of software) projects have many traits in common with projects in other disciplines. But ignoring their specifics is almost as wrong as saying that software projects are completely different than other projects.
Managing a project is managing a project. If you are building a skyscraper, constructing a ship, running a presidential campaign, or researching new medication, your project has these three things: budget, timeframe and scope.
Managing a project means primarily managing these three: cost, time and scope. There are other things you are likely managing on your projects: quality, communication, risk, people and procurement. Since all these processes interact, you need to manage their interaction, or integration. According to PMBOK, this is what you do, no less, no more.
This is a bird’s eye view, and in itself it is correct, for software projects equally so as for any other kind of project.
A great book by Fergus O’Connell, How to Run Successful Projects III: The Silver Bullet (3rd Edition) (which should be no news to any software project manager) gives a practical perspective over this, which it calls “The Ten Steps”:
And again, this list applies to just about any type of project there is.
It does, because it is generic.
However, something being generic doesn’t mean we should banalize the specifics of a field to which we are applying some general rules. Football, basketball or handball all have very simple principles, after all, they all have to do with teams focused on putting a ball in a target under other teams control. Yet, a successful football or trainer might be a total failure in basketball. Because specifics, not generics, in the end drive success of any activity.
There are many areas where software projects are very specific, and require a lot of appreciation for these specifics, from project management side:
These are just a few most important specifics of ERP implementation project management. All of these specifics can be addresses with general rules of project management, such as those explained in PMBOK, as all of these still relate directly to scope, communication, time, cost and risk management. However, two things often happen:
So yes, all projects are the same, but software and ERP implementation (and any other discipline for that matter) impose important constraints that must be taken into account.
Business Applications communities