What else can I do?

[livingston]

Hello Everyone,

I was asked to be the project lead for a primarily IT based project. I jumped in with both feet by pulling the team together and learning what had not been given to the IT group that they needed in order to move forward on the project. This project has been started and stopped several times over the last 4 years apparently. (red flag)

I gathered the information that they needed from team members and sent it to them. We have had 4 meetings per with touch point conversations in between with key team members. I sent meeting notes to everyone on the team for every meeting. Yesterday we had a meeting and they say that they do not have the information that they need and that is why it is delayed.

Keep in mind that I have several emails stating that the programmer has not been working on it for whatever reason (other high priority projects, out sick, computer crashed, etc). Now my boss is saying that it is my attitude that is keeping the team from moving forward.

What else am I supposed to do?

 

[ScottyUK]

Have you discussed this in more depth with your boss? It seems unlikely that he would make a comment like that without any justification, or if not justification then at least something that he perceives as justification.

What information are the programmers short of? Did they ask for it originally? Did you give them it? Have they tried independently to get it?

Too many unknowns, and I sense that you are not presenting a particularly balanced view of the situation because you are kinda pissed off.


----------------------------------

If we learn from our mistakes I'm getting a great education!

 

[livingston]

Youre right I am pissed off.

The programmers say that they are missing the functional specifications. (how is this expected to work) That is the very beginning for them from my understanding. They were sent this information with a request that if they needed additional info to contact me and I would request it from the team.

We have a whole list of tasks and subtasks that have been reviewed in every meeting. The question being ' is there anything that we need to add or change?' No changes other than the completions.

If anyone had said, we need xyz in any of the meetings, I would have tried to get it from the team. Am I supposed to anticipate what they need? (not happening)

 

[SLTA]

you need to get copies of all the emails you sent with info and requests for questions, copies of meeting notes, phone logs, whatever, and go to your boss with documentation. in that meeting, keep it calm and factual. all you can do is present your side as factually and unemotionally as possible and hope that it is given the weight it deserves.

 

[KENAT]

Project management 101, like design 101 etc.

Make sure you know your requirement and get all interested parties to sign off on it.

While it may not make any difference to the actual information available, detailing all the requirements etc. in a vaguely formal looking document and getting sign off from the relevant parties is often a good start.

This way if you've got explicit approval from the programmers, and then the programmer claims he doesn't know what's required you're a bit more protected.

E-mail chains & meeting notes are better than just verbal instructions but having the information spread over multiple documents/files isn't ideal.

KENAT,

Have you reminded yourself of faq731-376 recently, or taken a look at posting policies:

http://eng-tips.com/market.cfm?

What is Engineering anyway: faq1088-1484

 

[ctopher]

This is very common in IT. I unfortunately work in IT and hear this all the time. I can see why most of these jobs are being outsourced.

Chris
SolidWorks/PDMWorks 08 3.1
AutoCAD 08; CATIA V5
ctopher's home (updated Aug 5, 2008)
ctopher's blog
SolidWorks Legion

 

[TenPenny]

Next meeting, have your boss sit in.

Start off the meeting by saying, okay, guys, I've asked before what was needed to go forward from here, and I thought we were all covered. Let's start at the beginning, identify what is needed to go forward, and appoint a person to be responsible for delivering that information.

 

[GMcD]

I find that to be a general symptom of most IT and electrical engineers- zero imagination, initiative, or motivation to actually "get" the information on their own, and they want it handed to them on a silver platter by someone else. It allows them to avoid any decisions and blame others when something screws up.

As others have pointed out- vent here, you'll feel better, but then get all your documentation together to show that you have indeed given them everything they've asked for, to get the Boss off your back. Leading teams is a delicate art, and something I know I lack - I'm not a political animal and detest people who need to be told what to do....

 

[livingston]

Thanks everyone for your responses. I have sent my boss all the documentation and emails that have been sent to the team but he has not responded yet. I'm really not sure that he will.

In my real job, I'm not supposed to be leading projects either but he asked me to do it so I did. I am by no means a political animal either but apparently I am going to have to learn. I am also going to have to get used to the people who don't have any input but negative input.

Much calmer now;-)

 

[MikeHalloran]

I get the impression that IT departments everywhere begin layoffs when their backlog gets down to ten years, so maybe your expectations are too high.

Seriously, the "other high priority projects" means "YOU AIN'T SQUAT" on the IT department's "who can sh!t on me" scale, so your prognosis is not good.

Besides, you haven't fulfilled their request for a functional spec. You know what a military spec looks like? With small paragraphs, numbered, and organized, spelling everything out?

That's what they want for a functional spec; a description of every possible behavior of the software, including what triggers the transition between different behaviors, detailed right down to the colors. With numbers, so you can track progress by paragraph, and identify ideas the same way.

No one else is going to do it for you; >>>you, personally<<< have to write the specification.

When it's really and truly done, you'll be in a position to either farm out the damn job, or do it yourself. Screw IT.



Mike Halloran
Pembroke Pines, FL, USA

 

[Bribyk]

At that point you might as well learn the code yourself and make them look redundant...

 

[ScottyUK]

GMcD,

I ain't gonna even answer that opening comment.

Mike,

I see both sides of the situation with IT: they're IT guys, not engineers and they probably don't understand the engineering stuff that is so obvious that it an engineer wouldn't feel the need to spell it out. You need to spec things out in their language so they can work against the spec. If you don't give them a sufficiently detailed spec then it's not fair to get upset when what they deliver doesn't meet the spec you didn't bother to write. On the other hand there are IT departments, or individuals within them, who are just plain obstructive too.

livingston,

One thing I think I've picked up is that you use email a lot. Emailing stuff around is great, but get into their office and sit down and work through the problems face to face. Make 'em a cup of coffee now and then, show an interest in what else they are doing. Treat 'em like human beings and many times they'll respond by moving your project up the list.

Just a thought.


----------------------------------

If we learn from our mistakes I'm getting a great education!

 

[livingston]

Scotty,

You have a good point but, I work about 3 states away from the IT group. Other members of the team are in other locations as well. I meet with them face to face about once every couple of months.

 

[Andy512]

GMcD Says "Leading teams is a delicate art, and something I know I lack - I'm not a political animal and detest people who need to be told what to do...."

So, you are not a leader and hate people who must be led?

Is this self-hatred the root of your opinions of your peers?

 

[CorBlimeyLimey]

Andy512,

Being led isn't necessarily the same as being told what to do.

There are big differences between micro-managers, 'normal' managers, and leaders.

 

[GMcD]

OK, OK, you electrical guys can staop slagging me already! In the building design and contruction field I'm in, it is a majority of electrical designers and engineers I speak of. Even the Architects say the same thing. Whether it's a local/regional thing here, I don't know, but based on my experience in Western Canada, it's pretty common in that region, less so in the Excited States.

Andy- self hatred? Lots of psychoanalyszing from one post. Geez, took my post a little personally or what?

Scotty- my post wasn't a personal attack on individuals, I was speaking from my experience in my field. I have indeed met many electrical designers and engineers who could actually "consult" and provide valuable services, but it's been a rarity in my field.

 

[FreddyNurk]

GMcD has an interesting point, though in terms of relevance to the original thread topic it doesn't rate that highly.

In building services, everyone seems to want the low ball cheapest fee for electrical. That can be provided, if all the relevant information required to carry out the design is available at start up. When its not, it gets difficult, and its not the first time that I've been told to speak to some supplier somewhere as the architect has decided to use a product, then let us sort out all the fun details and run around chasing the information. If you're working for a consultancy then you don't have the allowance in the fees to chase up all the details, as if you'd allowed for it, you wouldn't have got the job.

I don't know about avoiding decisions or blaming others, thats probably overstepping the mark a little.

Exclude all the running around, and it appears that the electrical engineer won't do anything to get the information anymore. Certainly its been my experience from the other side of the fence and its just one of the reasons I'm glad to be leaving that section of the industry.