1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
|
1
00:00:00,090 --> 00:00:01,970
The third category of mistakes that I want to
2
00:00:01,970 --> 00:00:04,970
mention is product-related mistakes. A
3
00:00:04,970 --> 00:00:07,360
typical example of product-related mistake
4
00:00:07,360 --> 00:00:11,010
is gold plating of requirements. And what that means is
5
00:00:11,010 --> 00:00:13,710
basically is that it's very common for projects to have
6
00:00:13,710 --> 00:00:17,230
more requirements than they actually need. For example, marketing might
7
00:00:17,230 --> 00:00:19,090
want to add more features than the ones that are
8
00:00:19,090 --> 00:00:21,460
actually needed by the users. And of course having more
9
00:00:21,460 --> 00:00:25,720
requirements lengthens the project's schedule in a totally unnecessary way.
10
00:00:25,720 --> 00:00:29,250
Feature creep is another common mistake and consists in
11
00:00:29,250 --> 00:00:32,140
adding more and more features to a product that were
12
00:00:32,140 --> 00:00:34,650
not initially planned and are not really needed in most
13
00:00:34,650 --> 00:00:38,360
cases. And here there is evidence that the average project
14
00:00:38,360 --> 00:00:41,180
experiences about a 25% growth in the number of
15
00:00:41,180 --> 00:00:44,330
features over its lifetime which can clearly highly effect The
16
00:00:44,330 --> 00:00:47,580
project schedule. Finally, if you're working on a project that
17
00:00:47,580 --> 00:00:50,760
strains the limits of computer science. For example, because you
18
00:00:50,760 --> 00:00:53,350
need to develop new algorithms for the project, or you have
19
00:00:53,350 --> 00:00:56,670
to use new techniques. Then that project might be more research than
20
00:00:56,670 --> 00:00:58,450
actual development. And therefore, it
21
00:00:58,450 --> 00:01:00,600
should be managed accordingly. For example,
22
00:01:00,600 --> 00:01:03,910
by taking into account that you will have a highly unpredictable schedule.
|
