Hey everyone! There is a group of us that has been discussing project management as a whole and we’ve developed a ‘Best Practices’ section that we’d love to get your feedback on!
Granted, many of you are already doing this because you’re superstars, and many of you are pretty much doing this because you know your stuff, but some people might really benefit from ‘best practices’ to get a project moving along. This is sort of a best-case scenario which we hope most projects can follow, but it really is shooting for the moon.
Please review and take a look as we’re really hoping it can help improve our efficiency and productivity as a community so we can do more cool stuff, faster!
Thank you for kicking this off. As a new contributor to OpenMRS, I know that I will certainly benefit from applied best practices in project organization and management.
A few thoughts below:
If there is an existing model (ie, Agile, SCRUM, etc.) in the industry that can be localized for OpenMRS, it may be in our best interest to identify that model and adopt it. In the spirit of open source, there is probably some good existing work and models out there that we can leverage and reuse. I am curious as to how Linus Torvalds and team managed Linux development, or the organization methodology behind the Apache Project.
Snapping to industry standards may attract more volunteers, as they can gain experience in methodologies that support them in their day jobs.
A sample project template could be of benefit in providing “quick start” capabilities. Perhaps link this to a BOK (“Body of Knowledge”) that documents static content that will be common to all projects.
For example, you have defined some roles. We could document the description for each role, relationships and dependencies between roles, inputs that the person in the role needs to perform their work, as well as the output and role recipient of a resources effort.
I saw the following post and was impressed by the effort that this person applied to the actor-transaction diagram:
As we consider sample project plans, templates, and a BOK, we may also want to define “gold standard” examples of output. The post above might be an example that someone in the Business Analyst role may output, and set the example (and possibly template) for others to follow.
Also, I don’t know if there are language barriers across resources and role, but visual documentation like the diagram above may be a best practice is helping to oversome language barriers (if they exist).
The best thing I can say about our existing framework has been a Scrum/Kanban model. We have a group that is working together to build an extremely lightweight and versatile PMO. So that we can set standards that should be able to fit into the basic of development PM frameworks (Agile (Kanban/Scrum) and Waterfall) which should allow the team to choose what fits best for them. Torvalds/Linux if I go by what I’ve read pushed Lean and XP frameworks that were the grandparents of Agile.
I completely agree that grabbing to industry standards will help bring people in, which as we continue to build our documentation and improvements to this best practices document (many thanks to @ddesimone for it) we will be using terms and processes that are in line with both the PMBOK as well as Agile to make it easy for them to get engaged, as well as allowing the new or recently minted PM/BA/PO the ability to use the skills they’ve learned at school.
The “BOK” you reference is exactly what we are currently building in our PM working group.
+1 for the digram reference as well, good example for us to use , thanks!
The rest was great as well, and is definitely our intent. Keep the suggestions and conversation going as we start posting more from this working group (and feel free to join us if you like!) Details coming in a post soon.
Thanks for your awesome feedback! I agree that we should adopt industry standards and I believe that was the source for the proposed Best Practices.
The documentation on the OpenEMPI model appears to be what it is after many revisions, which isn’t a bad thing. I’d just like to point out that it didn’t start that way and I think what we’re proposing is a more cohesive and guided beginning to projects where the documentation, however large or small, is well-organized and is a solid platform to build on.
Thank you very much for the positive and supportive feedback. I look forward to collaborating with you and the OpenMRS team in creating a documentation model that aligns with your PMO best practices.
In support of that, I will read up on Agile, SCRUM, Kanban, and Waterfall models.