Locking in estimates before design!?

Getting some ball park estimates in for a project at the beginning, to give an idea of what is expected is fine. Locking them in and indicating that missing them is very bad (note - no designing has been done), seems irresponsible.

Hopefully I can get some idea as to what is driving the need for them to be solidified that early. I suspect it has something to do with a weekly meeting, but I'll have to have some conversations first.

Measuring Teams

I had recently read The Wisdom of Teams which left me with the idea that I've never worked on a real team. In fact any of the jobs I've had have had an averse environment for them, even though some could have benefit from having real teams. Now I've found myself thinking in my current job how I'd define some goals that are clearly defined and something the rest of the potential team could get behind and I keep getting stuck. Even if good goals were eventually around how would we know we got there.

This lead me into measurements where I poked around for a good book on that and decided to read Measuring and Managing Performance in Organizations. Robert Austin develops an interesting model for behavior and a compelling case for concern when measuring the performance of employees. It seems that a critical base for helping teams form is likely in working hard to ensure informational measurement can be kept while avoiding motivational measurement. This ties back to the need for trust among team members that is mentioned in The Wisdom of Teams.

That was silly...remember measurements do not make teams, but if a team has measurements then they should strive to be informative instead of motivational.

Requiring Estimates for Everything!

This could just be the programming side of me that doesn't want to worry about estimates coming out too strongly, but it seems odd that managers want everything to be estimated ahead of time. The current item in question is knowledge transition. I'm leaving the company I'm currently working at and need to sit down with the developer taking my place. We've come up with a number of things to review and we've got about 10 days to do it in. So I'm trying to figure out what the estimate would be giving my manager.

I suspect the concern is that the project needs to continue moving forward even while we're working on this knowledge transfer. So they want to account for this time in the main project. So that we have an "accurate" end date for the project. My issue that I have not faith in any accuracy of my estimate. The project has been in the works for three years and during that time we've been working in fairly isolated roles. So while I'm really not certain what it's going to take for my replacement to pick up on the stuff. I almost forgot the other catch is that my replacement is part-time.

Hrm - I just don't see how beneficial having the estimate is in the grand scheme of the project.

Blind Planning

So we finally pushed to try doing our development work in blocks of work that would be 6 weeks or less. We're also trying to push for the next block (yeah, I'd say iteration, but seems like a dirty word in my office place) to planned at the end of the first block. Unfortunately the project sponsors are looking for a project plan to be done and we have been unable to convince our project manager to put everything else in the next block as a place holder. This lead to our meeting this morning to attempt to plan out the remaining blocks of development. I suggested that if we were really going to do this that it might be better to actually have access to the requirement files so that we could double check details in the requirements instead of just a summary document (especially since the document we were attempting to plan from was not necessarily accurate with what it was showing since it is maintained separately). I got a flustered look and a restatement of the request.

Nice! My only hope is that the rest of the developers are also looking for coup and we just plan the next block after we get done the first one and let the project manager sort it out. Not the friendliest of approaches, but I feel unable to get our project manager to listen to any of our ideas.

Task Thrashing

I'm suffering from no clear direction by my project managers. I'm not sure if it is the way people have learned to do project management where I work of it is an issue with the project I'm on, but on regular basis what I'm asked for a status on changes. Unfortunately, it has nothing to do with previous tasks getting done.

I suspect this has something to do with the total chaos that is the requirements and there being no real prioritizing of them. Additionally there's no clear indicator of who needs to work on each requirement. Which I presume leads to complete confusion when trying to figure out what they are expecting to be done next.

I'm not sure what would be the biggest impact to getting clarity on this, but I suspect breaking down the requirements into smaller bite-sized chunks and letting the development team figure out who should work on them and not trying to assign them at requirement creation time might help.

Managers forget how it used to be...

Obviously this is not the case for everyone, but a colleague of mine who was a manager for a while before coming back to programming expressed that it is easy to forget what drives developers. Managers have their own sets of concerns that they need to drive for.

Document-itis

I'm currently on a project where it seems every time I turn around a new document has been created for a different way to view the same data. I'm not sure how to stem the tied of this swelling mountain of documents. Part of the issue is that the project is very far behind and management is desperately trying to bring in the hours yet still complete the work requested. So the thought of cleaning up the documentation and perhaps generating other views of the data gets shelved because we don't have enough time...even though we end up looking at data that is incorrect and making decisions off it because we didn't keep documents synchronized.