This is Laura Lee Rose, a business and efficiency coach that specializes in professional development, time management, project management and work-life balance strategies. In my Professional Development Toolkit package , I go into professional development and real-world IT topics in detail. If you are interested in more training in these areas, get signed up
There are several ways to fall behind in a project. Most times we can rebound from them But these three mistakes are very hard to recover from. Please keep an eye out for them:
1) Not verifying that everyone understands the success criteria.
For example: Make sure everyone has the same definition of DONE and the quality criteria. A developer may feel that “done” means that he has completed his section of code. But the project definition of ‘done’ means design spec written, reviewed, approved; code developed, reviewed, tested, unit tests done and automated, all Severity 1 defects fixed and retested on that section of code.
Make sure the entire team (business analyst, developer, tester, technical writer, technical support, managers etc ) is using the same definitions.
Make sure the entire team (business analyst, developer, tester, technical writer, technical support, managers etc ) is using the same definitions.
2) Not sharing the reason behind the quality metrics.
For example: The quality metric goal is to fix, retest and clear all high-level, Severity 1 defects by 6 weeks before code-freeze. In other words, the team’s goal is to have the count of 0 (none) High-level, Severity 1 defects at the 6 week milestone before code-freeze. This is because with every code change, there is a 10% chance of introducing new defects or uncovering hidden defects. In this example: Retesting 100 fixed defects has the possibility of finding another 10 new defects. By finding these new defects 6 weeks before the code-freeze allows you to fix and retest those 10 fixed defects before code freeze. If people do not understand the purpose of retesting the logged fixes that many weeks before code-freeze – they may decide to just close the fixed defects (to meet the 0 Severity 1 defect goal) without retesting them. This meets the 0 Severity 1 Defect metric criteria – but bypasses the intent or reason for the quality metric. If you just close the fixed defects without retesting – you have released with an additional (potential) 11 defects that would have been found/fixed if you had retested prior to the 6-week milestone.
Make sure everyone fully understands the reason behind the procedures and not just number goals.
3) Not selecting and reporting meaningful metrics.
Every project’s quality, forecasting, and progress metrics should be re-evaluated for each project. While past project report templates may be relevant – it should not be assumed that they are relevant. You still need to re-evaluate for each new project. Every project should have a mission and goal. Every metric that you report needs to support the mission and project goal. If you can not align the project mission and the metrics you are reporting, you are not emphasizing the meaningful targets.
In my Professional Toolkit, I provide worksheet, templates and guidance on how to accomplish these things. In my Book of Answers: Companion piece to the Professional Toolkit, I have 100 work-life scenarios like the above. The scenarios show how to accomplish your goals in similar situation.
For more information on how to get this toolkit or the “Book of Answers”, please contact:
For more information on how to get this toolkit or the “Book of Answers”, please contact:
vConferenceOnline.com/Bits on the Wire, Inc.
6420 E. Broadway, Suite A300
Tucson, AZ 85710
520-760-2400 or (877) 853-9158
info@vconferenceonline.com
Try it and let me know what you think.