Working with developers that used to only code without having the big picture or documenting/communicating any use case scenario, user story or functional/non functional requirements and pretending this is what agile and that’s because they are devops.
With the enterprise low maturity on project management, I’m trying to do reverse engineering to document a mini project charter and do a kickoff with the absence of any kind of handover and support.
1- Do you see other ways to start/continue the projects in progress?
2- What would be the advise to improve the way of working while keeping in mind delivering value fast and not overwhelming them?
3- What is the good enough documentation for an adaptive lifecycle?
If the main structure of work of your project is agile, must do reverse engineering to obtain a Backlog, and then determine the tasks already completed and the ones that still need to be done, that must be organized in sprints (of adequate length, to not overwhelm the team with quantities of work).
I recommend you this newfangled project monitoring solution that combines agile with global indicators. Every team member can be included in a Trello dashboard, to update the state of his respective tasks. Then, the information is translated into a global indicators panel, that can be shared with management supervisors. To get more information about this solution, visit this site: https://www.facebook.com/Teleworking-Monitoring-107369664431280/. Also, contact them at [email protected] Saving Changes...
Do the developers have an operating model which allows them to work closely with the users and stakeholders? Do they have business product owners who set goals and priorities and ensure the team are delivering real value? I suggest you focus on the team's way of working first rather documentation.
If and when the development work has clear ownership then talk to the business owners about what they think of the team's work and what documentation they think is needed. Software development often works best as a BAU process of continuous improvement. In those situations with a truly adaptive lifecycle a project charter may be inappropriate because the product rather than the project defines the scope of work. Saving Changes...
Documentation needs to serve a purpose and be minimally sufficient in doing so, especially if it is a by-product of the delivery process and not a stakeholder (e.g. end user or support staff) deliverable.
Having said that, the nature of the documentation should take into account regulatory requirements - for example, projects in the pharmaceutical industry will require significant validation documentation.
It is also a good idea to make it easy to maintain and use the documents during and after the life of the project - an online wiki might be a better option than standalone documents if there is expected to be ongoing evolution of the outputs from the project.
