For another example of the story seemingly being more important than reporting, see:
I came across a good post about an article reporting on burglaries that had occurred by using Facebook to determine when folks weren’t home. The point of the post was that Facebook’s role in these thefts wasn’t quite as serious as the media made it seem, and secondarily it was about the responsibility that a journalist has to investigate and report on the unbiased news. I thought the lessons about using Facebook would be useful for most, and I also enjoyed the point that was made about reporting.
You can find the article here:
Note: This is slanted towards technology product development.
Short post today around thoughts about managing technology product development projects out of crisis.
Whenever I have come on board projects in the past that need course correction, the first thing that needs to happen is to level set on where we are in the product development cycle and ensure that we have a plan in place to deliver.
This includes documentation/design around major features (to ensure we understand how we will be implementing and that estimates are as accurate as possible at this stage), a list of risks built by the team with priority/mitigation/contingency, test plans to understand how we will be executing on validating the product (among other plans, like operations), and an analysis of when we might expect to meet the release criteria.
It seems simple, but we do not have a plan if there are approved change requests that are not included to be executed. Scope and resources should be set before we can be fairly confident that we have a plan we can execute successfully (of course schedules aren’t necessarily “set,” since they are probabilities). Product Management must also understand that it will require discipline to ensure that no unnecessary change requests are added to the plan (there will always be change requests, but we need to make sure that they are important enough and reach a significant number of users to be worth the delays). In general, the entire team needs to be focused on shipping the product. QA Engineering could always ask for more time to test, Development could always refactor or implement a cool new technology, Product Management can always ask for more features, etc.
The entire plan to deliver on a product should already include the late-arriving features, and thus at that point they are no longer “late-arriving” but part of the plan. There should also be a risk buffer built into the schedule to accommodate the realization of risks (which stakeholders should be aware of), and each team needs to be accountable for their commitments. Anytime a risk is realized, the stakeholders should be aware of the time that is being eaten out of the buffer.
Of course, managing a project out of crisis isn’t only the job of the Project or Program Manager. I would also put my most experienced Development and QA leaders in charge of righting the ship (if they aren’t already) on both sides and ensuring that the Development plans and QA plans are the right ones and are being executed.