… some key points
waterfall
Every project and product development start with the idea to create something, followed by a feasibility study, advantages vs. disadvantages, benefits vs. costs, and know-how and resources available or needed.
Then the (engineering) proposal and/or the marketing requirements document with goals and intentions spelled out, prerequisites and time frame determined will be the basis for the functional and specifications documents. After review by all parties involved, affected, or interested, the design document will be released and signed off; and the development can begin!
experience
The amount of efforts and time needed for the preparation is very well dependent on the task or project at hand. Is this a new functionality we want to add where all necessary building blocks already exist; or do we want to create a complete new product, where everything is basically built from the ground up. Perhaps we have empirical experience, say, when retiring an older system by a complete new development; or we’re faced with a learning curve to understand and layout for a brand-new hardware standard or the interface of a new software feature.
iterative
Based on the scope of the work, the prerequisites and the efforts involved, it may become imperative to not just go from the development to testing —assuring, the look and feel and the functionality of the product is inline with specifications and requirements — and then to release. Development may face obstacles or something unforeseen, and that could make it necessary to even go back to the design board. Also, in case of test fail, we have to go back some steps within the water fall(s); making it an iterative process.
work in parallel
It makes perfect sense to implement overlap, so that various teams can work in parallel. I.e., why should Test wait until Development had fully completed the product. As soon some framework is ready, let the testing start! Then continue with each new enhancement and/or — in case of incidents reported and resolved — corrections that are ready to check off.
hand-in-hand
A good project plan lays the groundwork for efficient hand-in-hand of processes and people, adding transparency and reporting. Work Breakdown Structure means nothing else than dissecting (larger) tasks into smaller subtasks that are easy to oversee and to handle, and, of course, monitor their progress and hand-off. Where a development task cannot be split into small segments, we’d apply some timeline and report on a percent completion.
report
Progress reporting can be in some fixed time intervals or just observing the approaching and the completion towards defined milestones.
Reliable tools assist setting up, updating, and monitoring project status, to help communicating overall progress to team, stake holders, and others.
Even more important: to learn ahead of time when indications point to potential problems affecting schedules of tasks and successors, and resources, lastly the outcome of the project!
sprint
Scrum very much formalises the process into small sub-tasks or “Sprints” with regular meetings in set intervals. This method has advantages to, say, more junior developers who’d appreciate firm guidance and focus and to learn to be self-efficient and cross-functional as a team. A great tool when you need to get the team aligned for critical high priority developments and need to release products for deployment in short intervals. It can add quite some administrative overhead though, taking away valuable development time and resources.
kanban
Kanban (“visualise the cards”) is less structured and is driven by a list or a backlog of tasks, not so much by critical completion dates but more by advanced planning for just in time delivery.
Often, a mix of Scrum and Kanban principles is used.
devops
The term DevOps describes the hand-in-hand of development and test and system operations as one team for fast engineering and installation allowing for very fast turn-around of deployment of features and fixes.
This process is especially used for live environments, such as enterprise systems, online services, and other mission critical systems.
re-invent
We have to be flexible (and embrace) when prerequisites and assumptions and goals change in the midst of a project. With team members (and I use the term team very broadly) we’ll discuss and agree how to proceed with the project and the tasks at hand. The project overall might become obsolete. Or some tasks will have to be redefined or just refined. And there could be new tasks added, interdependencies identified, and order or sequence established in lieu of available resources (staffing, development tools, availability of test-beds, and other constraints) and (new) priorities..
monitor
There is always a fine balance between the need of monitoring and reporting the progress of the project, updates and risk assessments for stake holders, getting the team members in sync, etc.; and not distracting the development teams in their work.
Software and hardware development is a very creative job, and as novel authors often have to overcome a “writer’s block”, or art work creators awaiting the “Muse’s kiss” to continue, development likewise is not working on command. Interruptions may not be a simple “pause & resume” process and could negatively impact the mental process.
lean
Using a lean management means to enable trust in every team member, working towards the common goal, getting the tasks done as planned while alerting on any unknown and unforeseen problems.
Be the conductor (like in a big orchestra), empower cross-functional teams (including mediating), learning from past experience and continuously find ways and methods to improve communication and processes, removing overhead and obstacles for smooth “sailing” and work.
by the book
Processes and methods of project / product management is nothing new and has been in place since … ever. (E.g., had the construction of the great pyramids been possible without creating and executing a very elaborate plan?)
Spelling out rules and methodology and defining processes serve as a teaching tool to help beginners and junior folks as well as more senior managers, providing the groundwork enabling them to work “by the book” while gaining experience or “hang” of things.
instinct
There are areas that cannot be just learned, no matter how thick and detailed the book. As program manager you need to, well, “hear the grass grow”. You need to have an instinct or a sixth sense to foresee when something could become a problem. And find solutions.
3-Cs
In another blog I described where I created and executed a roadmap and mentioned the “3-Rs” of good testing: reproducible – repeatable – reliable.
I want to finish this story with what I see are essential for a successful program manager: communication – communication – communication = the “3-Cs”!
Last Note
Please follow this principle:
Quality is not what you can cover up. Quality has to come from the core!
Jürgen Menge
San José, California
July/August 2019