Key Elements of a Successful Project
Matthew at Ganthead just released their sec_on_d part of the article Ingredients for a Successful Project (part2 ) which urges me to comment some of the statements in the article (you need a free registration to read them…)
Developing a new application may cause the need for new infrastructure, hardware, software, etc. If possible (and I highly recommend doing so), split a project into two separate projects. While the new infrastructure is being decided upon, installed and tested, separate projects can handle the development of the application, which also has its own set of design, coding and testing.
No TPM> should have the burden of managing these as one project-especially when it’s never been proven in the organization. However, it’s probably smart to have the same TPM manage both projects, although it is not necessary.
Well - as long as both projects do not relate to each other, or the application development can happen much later, I am fine with this. Don’t get this wrong and start developing the customer’s needs on an application framework that is old or just crap.
If you need new infrastructure in your project, you need to build that new infrastructure - and wait for it to complete> You would have a hard time explaining your clients that the application is 90% done, while you just have to migrate everything to the cool new infrastructure you just built “by-the-way” .. don’t you think? Also for your team it would be mega-frustrating to adapt their code to the new infrastructure… and don’t get me wrong: this has nothing to do with “refactoring” … refactoring refers to improving YOUR> own code (hence a mental code cleanup as well…) - moving to a new infrastructure is the opposite - changing your code to <span class=“caps"RUN ANYHOW again with those new libs that the lab spit out after a few months of “creating a perfect world”
Pick Your Team
I know in a perfect world this would be possible. However, there are those projects that require key resources and it’s okay to be selective in forming your team.
NO >- be as picky as possible - every team member IS> a KEY RESOURCE» every team member you take “because it could fit will cost you 20-30% team performance for the whole remaining team to bring him where you thought he should be… if you are to select new team members every hour NOT SPENT WISELY> in selection process will cost you a <span class=“caps"BIG multiple in development / testing / rollout costs for re-writing or fixing of a bad developer’s results or even architects design… with that kind of effort you are better to do it yourself.
It’s a good practice to manage the risks before they turn into full-blown issues. However, no matter how well you mitigate a risk, issues will arise. In this case, tackle all issues first. Make sure those involved in the issue are aware of the impact and consequences, then decide who the action agent will be for resolving the issue. And put a timeframe on the issue so as not to have the issue extended and prevent a future risk of creating a non-manageable issue.
Yes - manage risks. If you know nothing about risk management, then start reading
Set the timeframe for your own re-check. If you don’t manage the risks who would? ( unless you assign a specific risk manager to get you out of your optimistic PM views … )