After reading the story above, there are a few things that come to mind that we do where I am currently working:
1. Maintain a Risk Register. Any project manager worth there salt would want to know what the risks, how to mitigate those risks and what they are going to cost. If you are being asked to cut corners, inform the PM to add your concerns to the register. The project is doomed to failure if the risks arn't known or mitigated.
2. Most consultants would have a formal reporting mechanism to the client, a client progress meeting for example. If you have concerns a very powerful way of communicating those concerns is to formally report it via the client progress meeting. If the Project / Programme manager is not taking your risk on board, the project sponsor and business should be in a position to bring pressure to bear and deal with the issue. I myself have been in several situations where problems have come to light, that we highlighted on the client progress report many months earlier and effectively covered ourselves by highlighting the risk.
3. If you are consulting, there is an air of professionalism to highlighting issues as you see them. Ultimately in the end you will get a good reputation and be offered more work. I have seen this happen in many places. Before anyone chips in with scope creep and people going out of business, if you are silly enough to bid for work without including sufficient contingency both in time and price to cover unforseen issues and not fully understanding the problem, then you deserve to lose money.
4. Microsoft, yep I know most of you hate them, but they have a very effective programme management framework called MSF. One of the features of it is a process called War Room. In this, All functional and technical leads, Business Analysts, Management and sometimes developers come together and quickly discuss what they are doing and the issues they are having. This is an excellent way for a consultant, or anybody in fact, to highlight issues that may not be making up to management and in many cases come up with a solution.
I could go on for hours but my fingers are starting to hurt:)
The company I currently work for, and the previous one used the concept of peer code reviews. This stops a rogue developer adding backdoors / 'little suprises' that could leave your company open to litigation or embarrassing PR which could hurt your sales, and ultimately your job (in the current economic climate).
Peer reviewing has several advantages in a commercial environment:
Ensure the code is correct, ie no obvious errors that will come and hit us during acceptance and therefore hit our bottom line
Ensure the code is efficient and well written, at the end of the day, when the project is completed, the client takes ownership of the code. It's its badly written, this could impact repeat buisness
Ensure the developers are not putting 'back doors' in. On a large development project, you should have a development environment and a seperate acceptance environment mirroring the production environment. Developers should never get anywhere near production testing code.
Peer reviews can help sell your company, if the client needs to be assured that you will develop quality code, then the peer reviewing concept will work in your favour.
Developers placing 'Easter Eggs' and 'Backdoors' in programs to me suggests poor management by their team leaders / project leaders / project managers. If legitimate back end access is required, by personnel authorised to perform it, then a mechanism that the client is aware of should be used such as a troubleshooter logon / password.
Slashdot Mirror
After reading the story above, there are a few things that come to mind that we do where I am currently working:
:)
1. Maintain a Risk Register. Any project manager worth there salt would want to know what the risks, how to mitigate those risks and what they are going to cost. If you are being asked to cut corners, inform the PM to add your concerns to the register. The project is doomed to failure if the risks arn't known or mitigated.
2. Most consultants would have a formal reporting mechanism to the client, a client progress meeting for example. If you have concerns a very powerful way of communicating those concerns is to formally report it via the client progress meeting. If the Project / Programme manager is not taking your risk on board, the project sponsor and business should be in a position to bring pressure to bear and deal with the issue. I myself have been in several situations where problems have come to light, that we highlighted on the client progress report many months earlier and effectively covered ourselves by highlighting the risk.
3. If you are consulting, there is an air of professionalism to highlighting issues as you see them. Ultimately in the end you will get a good reputation and be offered more work. I have seen this happen in many places. Before anyone chips in with scope creep and people going out of business, if you are silly enough to bid for work without including sufficient contingency both in time and price to cover unforseen issues and not fully understanding the problem, then you deserve to lose money.
4. Microsoft, yep I know most of you hate them, but they have a very effective programme management framework called MSF. One of the features of it is a process called War Room. In this, All functional and technical leads, Business Analysts, Management and sometimes developers come together and quickly discuss what they are doing and the issues they are having. This is an excellent way for a consultant, or anybody in fact, to highlight issues that may not be making up to management and in many cases come up with a solution.
I could go on for hours but my fingers are starting to hurt
Peer reviewing has several advantages in a commercial environment:
Ensure the code is correct, ie no obvious errors that will come and hit us during acceptance and therefore hit our bottom line
Ensure the code is efficient and well written, at the end of the day, when the project is completed, the client takes ownership of the code. It's its badly written, this could impact repeat buisness
Ensure the developers are not putting 'back doors' in. On a large development project, you should have a development environment and a seperate acceptance environment mirroring the production environment. Developers should never get anywhere near production testing code.
Peer reviews can help sell your company, if the client needs to be assured that you will develop quality code, then the peer reviewing concept will work in your favour.
/. posting.
Developers placing 'Easter Eggs' and 'Backdoors' in programs to me suggests poor management by their team leaders / project leaders / project managers. If legitimate back end access is required, by personnel authorised to perform it, then a mechanism that the client is aware of should be used such as a troubleshooter logon / password.
Just my 2 cents on my first