The major three - Health assessment for a test project

Let me start with some trivia. No project is the same. No project is dull. Every project is what you make of it. The interesting part is what you should do if you wanna make it.

Personally, I hate doctors. But in situations like this I have to act like one, which means, I start with collecting a medical history. And here are some hints regarding what to look for (as they say, including, but not limited to):

The checklist

1. Does your project have time limits and goal? Who is responsible for defining these two?

2. Is there any process in place? Project-wide, development only, test only, you name it. Is there any documentation to support that?

3. Is it iterative? How long is the iteration, if yes?

4. What is change rate? What are the sources of change? What is a nature of changes? How the project would mutate, if change rate was lower? Or higher? How changes affect the project in general? Are there tools to withstand external influence (technical, political etc)?

5. Is there a competency matrix (project roles vs project positions)? Are there any gaps (no roles covers, people qualification is not enough)? What about a balance of seniority levels (newbies vs experts ratio)? Now costly are newbies if there are any?

6. What management style is in use? Is it democratic or autocrative? Is it changes-oriented or conservative?

7. Is there any automation in place? Test automation? Process automation? What tools are in use (tools of production, tools of control and management etc). Does it include technical or non-technical tools, as well as material and non-material means of process management?

8. Is it a start-up? Or is it a regular well-insured and rule-bound business? Is it a risky version 1.0 that always costs 220% of standard effort?

9. What is with communication management? Is communication stuck because the structure is too flat and everyone is scared to open their mouth because of misunderstanding it may cause? Or do you have to hopelessly bang your head against an overcomplicated orgchart? What is with the orgchart and escalation routes? What is with knowledge sharing systems? Is the language you use for work the first language for the majority of the team? 

10. What is your budget. Although actual numbers may not be available for everyone to see, but it is important to understand what are the limits are dealing with? What can we count on?

11. What is with the test documentation? Test metrics? Test artifacts?

12. How is it going with the requirements? In what form do they come? Are they signed off (other keywords: approved, final, meet requirements for requirements such as testability, integrity, consistency etc)?

13. What is with configuration management? Environment availability? DevOps culture?

14. What is with the state of the code? Is code quality measured?

15. Are there any apparent risks? What is their impact and probability? How are they managed? Are they just quality risks?

16. Anything else that feels important in your particular case.

Measuring feasibility threshold

About three years ago I created the first draft of this for myself (and expanded it a bit for the purposes of this post). It is purely subjective and only based on my professional experience. In case you are not sure, if it is enough, I would recommend you to use PMBOK as a reference guide. Although it may seem an overkill at first, it is still a good example of a professional standard. And you'll certainly benefit from it even if you only read it's table of contents.

For measuring the threshold you can use the list above or build your own. Then you need to assign each criteria some weight (making sure that total sum of weights adds up to, say, 100 points). Now, if you subtract from 100 weights (maximum value) the criteria that were not met you will have a metric to measure total project feasibility. In case there is not enough information to properly assess something, I think it will be wise to write it down as 0 (zero).

And now for something more concrete

Basically, you need to do the following:

-- take the checklist;

-- assess the project criterion by criterion: if the the project perfectly matches the criterion, give it 100, if it matches, but there is some space for improvement, give it 50, if it does not match at all, give it 0;

-- sum all the given numbers up 

-- and then divide by the number of criterions

-- enjoy the result

Here is what your calculation may look like (I am using random values):

(100+50+0+50+0+100+100+100+50+0+100+50+100+100+50)/15=63.(3)

Congratulations, your project is probably above the feasibility threshold and is likely to survive despite the fact that that final value is relatively low.

In my experience, if calculated feasibility falls below 50 out of 100 (assuming all weights are equal) it's time for a nice little talk with your management. Because it is very likely that the project you are on has every chance to fail, unless it is fixed soon.