Leading and building a project, especially in IT

[Frank]

Let's start with the difference between leading and managing a project. You have to lead the development and build it before you can manage it. The only managing you can do on a new project is making sure the required resources are available on time and supply the initial goal.

But, as there seems to be a very distinct lack of leadership in the (IT) industry (to me), as the main developer you're almost always required to do most of the leading as well. Prod the manager to allocate the resources and buy the stuff you need, for which you first need to sell it to them, for which you first have to do a decent premilary research, which is most of the time seen as a waste of time, and for which nobody wants to pay.

Essentially, the customer wants you to hand him a fixed price, shrink-wrapped product before you even know what it is they want and/or need, and all the managers are second-guessing you, kill all initiatives not ordered by them and offer that same plan some times later as their own, "improved" by all the politically required "do" and "don'ts".



Whatever. That's how it works. My question:

Do you try and give them what they really need, jump all the hoops required to have that happen and make yourself impopular with some of the managers while doing so, so you can do it right, or do you just draw a line underneath the original goal, give them that and point out it's exactly according to those specs when they complain that it isn't working?

 

[ERP]

Let's start with the difference between leading and managing a project. You have to lead the development and build it before you can manage it. The only managing you can do on a new project is making sure the required resources are available on time and supply the initial goal.

But, as there seems to be a very distinct lack of leadership in the (IT) industry (to me), as the main developer you're almost always required to do most of the leading as well. Prod the manager to allocate the resources and buy the stuff you need, for which you first need to sell it to them, for which you first have to do a decent premilary research, which is most of the time seen as a waste of time, and for which nobody wants to pay.

Essentially, the customer wants you to hand him a fixed price, shrink-wrapped product before you even know what it is they want and/or need, and all the managers are second-guessing you, kill all initiatives not ordered by them and offer that same plan some times later as their own, "improved" by all the politically required "do" and "don'ts".



Whatever. That's how it works. My question:

Do you try and give them what they really need, jump all the hoops required to have that happen and make yourself impopular with some of the managers while doing so, so you can do it right, or do you just draw a line underneath the original goal, give them that and point out it's exactly according to those specs when they complain that it isn't working?

It's a hard call, there is a danger going outside of supplied specs, if your provided solution doesn't work, your responsible (as you should be), my preference in my own field is to get the requirements worded in the right way upfront, understanding what can and cannot be understood upfront, giving developers the flexibility to solve the problems rather than to implement provided solutions.

FWIW it's the same in all software fields. I worked in Aerospace 20+ years ago on a flight control system, one of the provided spec sheets was clearly wrong (it was an obvious typo) I asked my manager at the time about it, he told me to implement it as written since it had been approved by the customer. Changing the specification at that point would have cost too much time and as a result money, he figured it would turn up in testing.

 

[darkblu]

one of the provided spec sheets was clearly wrong (it was an obvious typo)

let me guess - a minus sign in front of an flight altitude parameter.

 

[ERP]

let me guess - a minus sign in front of an flight altitude parameter.

No it was a line drawn wrong in a flow diagram.

 

[DemoCoder]

I think you're over generalizing. At my company, we have product managers, and development managers. Development managers simultaneously do project lead and management grudgework. They can only come from a technical track->management track, in other words, most development managers were prior senior developers. Above development managers are directors. Directors usually manage multiple development teams. The directors of such teams are also usually technical, but usually don't do any design or coding, but merely facilitiate teams working together.

Dev managers help do design, sometimes write code, gather requirements from customer/product management, and write functional specs. It's a thankless job, usually 2x the work of a senior development, plus alot of paperwork (handle budget, HR, etc) plus its *your ass* on the line when something goes wrong, and the pay isn't much better. The major difference is that it looks great on your resume. And as there is ageism in the IT industry, you better have some management credentials by the time you reach 40, cause they don't go around hiring high priced 40-year old developers for positions they can fill with college grads or Indians. Unless, you want to do consulting all the time.

 

[Frank]

I do like the project leading, but I don't like the paper shuffling one bit. But then again, at my current job I'm encouraged to do it as I see fit. And we think good programmers that fit in are pretty hard to find, so I'm happy. And every project is completely different from every other one.

Then again, I do some or all those things you described, depending on the project. And not only the IT part: the machinery, electronics, control logic and logistics are fine by me as well.

But that doesn't matter. It's just always the software project where things get problematic. Possibly because it's very abstract and so hard to get for non-programmers and such. That isn't helped by the fact that most higher IT educations still focus primary on economics and management. And it isn't helped either by the idea that in IT everything is possible and easy to do.

And, most of the time, the customer consists of multiple groups of users that all have very different goals and wishes. Which is the main reason why it's so hard to get the specs right at the start. The first time you go to the customer and start talking with them, you completely revise everything you designed to that point in your head.

And yes, I know that shouldn't happen. But it does. So, how do you handle those things? Try and make the initial specs yourself? That isn't an option most of the time.

 

[KimB]

It seems to me the only thing you can do is attempt to get your company to inform the customer of potential errors or shortcomings of the spec, but write the code according to the spec while all that's going on.

 

[Frank]

It seems to me the only thing you can do is attempt to get your company to inform the customer of potential errors or shortcomings of the spec, but write the code according to the spec while all that's going on.

Personally, I have a problem with that. I want to do it right.

And, most of the follow-up projects come from "making things better" and actively participating with the customer. But some you lose, and that generally weighs harder. The follow-up project is unforeseen, but cancelled projects are big, red marks.

 

[KimB]

Sure, but the question is, how bad is doing it according to the spec? Is it a clear error in the spec that would totally break the intended functionality? Or would it just be better to do it X way that is little or no more work for you?

In the first case, you should obviously report the problem, fix the error, and deal with any flak that comes from other people expecting something else down the road.

In the second case, then it really isn't your problem to solve. You should obviously do the curteous thing and do what you can to inform the customer of the problem, but changing functionality could possibly mess up other peoples' code (or whatever else the code interacts with).

 

[Frank]

Sure, but the question is, how bad is doing it according to the spec? Is it a clear error in the spec that would totally break the intended functionality? Or would it just be better to do it X way that is little or no more work for you?

In the first case, you should obviously report the problem, fix the error, and deal with any flak that comes from other people expecting something else down the road.

Yes, but changing things is pretty hard. Because it's not a single decision to make. You first have to talk with the people it would impact, see what they expect, and then talk to the person responsible. Who will probably talk to the bosses of the people it impacts, and before you know it it has become a big discussion, and multiple things have to be considered for revising. And a question of who is going to pay for all that.

In the second case, then it really isn't your problem to solve. You should obviously do the curteous thing and do what you can to inform the customer of the problem, but changing functionality could possibly mess up other peoples' code (or whatever else the code interacts with).

Yes, true. But that is not only what can make it a big success, but also what opens the door to follow-up projects.

And both things can make it lose you money. Which doesn't even have to be a problem if it creates a lot of additional projects for your company.

But while it's not my decision to make what the customer and my company prefer, it's up to me (or the person who's taking the design lead) to create those possibilities and follow them through.

And that's what this thread is mostly about.

 

[KimB]

Right, of course, and you'd be absolutely remiss in your job, I think, if you didn't attempt to point such possible improvements/problems with your supervisors (or the customers of the company, if you talk directly to them). Because it really is the coder "on the ground," so to speak, that has the best idea of how to improve some specific aspects of the software.

 

[DudeMiester]

It seems to me the only thing you can do is attempt to get your company to inform the customer of potential errors or shortcomings of the spec, but write the code according to the spec while all that's going on.

On the other hand, you could incorperate into the spec a clause that allows the developer to fix obvious error in a streamline fashion. Although, one must be careful to specify errors and not improvements/optimisations. Also, I think you should be clear on what parts of the spec are functionality issues and what are implementation issues, then leave implementation up to the developer. I really hate it when the client, for example, decides that their website must use only .net technology even when they have never programmed a thing in their lives. Issues like that are the developer's concern, and that should be clear in the agreement.