How can the progress of designing a large programming project be measured to assure managers that employees are in fact moving forward?
+1
A:
By the changes in the project design documents, considering the changes are worth taking into consideration.
ilya.devyatovsky
2009-08-25 22:15:36
I was going to say this as well, but thought this would refocus on generating huge volumes of documentation instead of focusing on as little as possible to still communicate the desired results.
John MacIntyre
2009-08-25 22:21:20
that just means you have to have someone in the area that'd check the latest changes and make sure they're not just volumes of documentation but something that describes thought process
ilya.devyatovsky
2009-08-25 22:26:43
documentation does not effectively measure completion of work. It only measures completion of documentation. If you have to assign a "documentation nanny" to monitor the docs against the code then I'd say you need to re-think both your team and your measurement standards.
free-dom
2009-08-25 22:35:51
"documentation does not effectively measure completion of work. It only measures completion of documentation" --that's what the question is about
ilya.devyatovsky
2009-08-25 22:45:02
otherwise it's sound "How can the progress of development... "
ilya.devyatovsky
2009-08-25 22:46:22
@ilya.devyatovsky - "It only measures completion of documentation" ... in my opinion, if you 'complete documentation', you've wasted time and money.
John MacIntyre
2009-08-25 22:59:43
so how then does the quantity of documentation equate to completion of designs? Do you decide that each design must have 5 pages of documentation? Or do you decide up front that certain features require so many words and so many figures/diagrams? Remember that management is going to want to see numbers and percentages. Things that can be used in estimating future performance. It seems any quantification you apply to documentation is going to amount to something arbitrary and not suitable for tracking purposes.
free-dom
2009-08-25 23:00:14
For that you should have someone who'd track the documentation changes and see if they're worthwhile.
ilya.devyatovsky
2009-08-25 23:33:05
@John MacIntyre - by documentation I mean project design documents. Are we mixing the terms? As soon as the project design documents are completed the dev team can start on the project, but that's not the part of the qq.
ilya.devyatovsky
2009-08-25 23:38:53
+5
A:
The only real measure of progress is working software.
[Yes I misread the question, but it's still something to think about. I would make delivery of software the goal, and let other activities follow from that]
Jim Arnold
2009-08-25 22:15:52
it's still too abstract. Say you have a project that'd take 20 programmers work 3 years. You'd have working software not that soon to measure the progress.Anyway project design would be the first document you're going to produce *before* you start the project. And that would also take time and you need to make sure the designers of the project are not just wasting time and your money. Think from the investor position.
ilya.devyatovsky
2009-08-25 22:31:11
While he misread the question, I still think this is the correct answer - in my mind, the question itself is erroneous. Asked another way, "How can I tell based on a bunch of papers, that I can eventually get a working program?" I don't think there is a document that can prove that. OTOH, a high-level document may give me reassurance that the people involved are competent, but only if I know enough about the domain to judge their competency based on their design.
kyoryu
2009-08-26 02:03:03
@Ilya - The point is that waiting 3 years before you get any value out of the project is far too long. Reduce the scope, get a release out as early as you can, and you won't be worrying about progress so much
Jim Arnold
2009-08-26 13:12:18
that's a mixup of the idea of design process. a priori I think project design is a set of documents that describes the development process in pretty much detail, such as standards, frameworks, modules, programming language, reasons, etc. used
ilya.devyatovsky
2009-08-25 22:25:22
absolutely not. deciding what can be accomplished in a given iteration at the beginning of the iteration is an important step towards tracking a team's progress. After a few iterations, management can also use this information to develop projections based on velocity estimates provided by the number of points a given team can complete in a given amount of time.
free-dom
2009-08-25 22:33:02
you're still referring to tracking the project progress, not project design progress. Let me know if you wish me to explain the thought in greater detail.For the question itself the situation looks exactly like this:you have a project large enough, you need to make some design choices first, you give the task to someone and wish to track his progress before giving out the project to the developers.
ilya.devyatovsky
2009-08-25 22:44:23
again, absolutely not. In the same way programmers can divide up the work of implementation, architects can divide up the work of design. So long as there are some user stories or features to have design work for there can be planning. Architects can vote on the relative size of the design of each subsystem. This also works for visual design shops, where the end product isn't a software product at all but is instead a brochure or marketing package. Agile and scrum is a methodology for iterating and tracking projects, regardless of the field of work.
free-dom
2009-08-25 22:55:41
+1
A:
It's actually pretty difficult--doing a significant amount of design up-front is hard to do and hard to track... It takes at least one Very Talented Programmer to design a small to medium sized project, and one Very Talented Programmer plus a team of good programmers to design a very large project.
Without a one-in-a-thousand programmer on your team, upfront design will almost certainly fail to deliver on time (and probably fail completely) on any project above "Trivial" in size. This is why people moved towards agile.
That said, if you have one of those programmers on the team, he's smart like Jon Skeet and will be able to solve this question for you--and your management will know it and won't have to be re-assured.
If you don't, you might consider an agile style iterative design--it works and with iterations there is no question on design time vs coding time, they get integrated together. You also get all the advantages of agile reporting like burn-down charts. Once managers get used to the quantity and accuracy of information they get out of agile systems they generally fall in love with it.
Edit/ps... One in a thousand may be a vast understatement...
Bill K
2009-08-26 00:26:24
A:
You did not say at what level in the project you are, but it sounds like you have a detailed design and plans. If you don't have a detailed design and/or requirements specification, you need to make sure you have agreements on the work to be completed and you should have an estimate of the amount of work to be completed. In addition, may sure that any changes in the agreements/specification must be negotiated (for additional funds and schedule). This is to hopefully minimize scope/requirement creep.
After you have completed that, depending upon the project size, you might want to divide it up into phases, with incremental deliveries. This will help in determining progresses on a large scale. You need to make a trade between small amount of time and large amount between deliveries depending upon the scale of items and what can be done. To many small schedule may not have enough items to do anything, where with large time frames, there could be a lot to be done to get items working together.
With the above information (estimates of effort/code, schedule) you can lay out a plan of how much work needs to be completed on a weekly/monthly basis. This can be done with code count to see how much work is begin completed and also give you an indicate of how accurate was the estimates to the amount of work.
For a simple example, suppose a program is estimated to be 1200 lines of code. To construct, code and test (I'm not including design and/or integration with other systems) a person could do 300 lines a month. With that, it should take 4 months to complete.
Then you need to measure the work completed against how much of program is completed. So at the end of the first month, you count the code completed (350 lines) and he person estimates they are 20 percent completed. Based on this, the productiviy is higher then expected, however if they only have 20 percent completed and they needed to have 25 percent completed, you know you have an issue of the estimate being off. You can look at various items such as cutting scope, or adding another person, or trying to determine a more accurate estimate and negociate schedule and funds.
Integration can be planned seperately as a level of effort to get things to work together, but it should be opened ended. In this case you take credit for completing activites as a percent over a time frame.
You can change the time frame with the above to be bi weekly or other depending upon what you need to show management to show progress and give them a idea if items are on track and if not, how to allocate the resources to complete the task.
Other areas to explore would be an Earned Value system for reporting. There are probably several examples of this and this tends to be what some companies are moving to for reporting status and progress on projects.
Glenn
2009-08-26 01:06:47
A:
When I managed manpower studies that lasted for three or more years, I had a list of the tasks required to be performed in each phase of the study. To measure progress I checked them off as they were completed (Adding new ones as needed or deleting those no longer deemed necessary). If you don't have any tasks being completed each week, then you have defined the tasks at too high a level. I knew who was assigned to each task and what they were doing to get the task done. I knew if they had some sort of roadblock that I had to clear for them.
When I managed multiple teams in multiple physical locations, I checked in with their team leads at least once a week (more often for some of the larger projects) and had them tell me what the team had been working on, what issues they were running into and what was on time and what was not. I managed 33 large projects at the same time going on all over the world and not one was late or over budget, so I know this method works.
The reason why some managers don't like it is because they don't want to have to do the work of actually finding out what is happening from their team leads (and some team leads don't pay any attention to what their people are doing). They would rather have so-called objective measure that someone uses to update some graphic (or in today's world a web-based dashboard) than actually have to talk to people to find out what they are doing. But those dashboards are misleading, they generally measure the wrong thing and in general the numbers on them are not an accurate measure of anything (it is usually laughably simple to fake up good numbers) if it was the right thing to be looking at.
HLGEM
2009-09-15 22:07:52