|
I ran my own schedule using scheduling software and told the (user) PM that they had their schedule and I would use mine. Of course, they could look at mine. I had projected finish dates. If there was a "due date", I made them take out "requirements" until my forecast matched their due date (year-end). And, no (I said), "more people" won't help after a certain point. I was never "popular", but never late.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
I had to jump in a project that was already way behind schedule. My first week there was almost only letting people explain me what it should be done and where we were. I tried to analyze what the previous guy was doing and then I called my boss, because repairing that mess would take me more time than starting over again. He let me do it.
2 weeks later, I was already moving the machine in semi-automatic. Then an appointment with the customer was done.
When they came the project manager was trying to explain things where I was internally hitting my head against the desk. Then the customer started asking for things and the project manager would open his mouth. At some moment I got tired and said... NO.
All quiet, staring at me...
Customer: Pardon? What do you mean?
Me: Because blah blah blah
Next day he was speaking with me using "Du" instead of "Sie" (the formal form in Germany) the other team members were and asked me if he knew him from before...
ME: No, I met him yesterday, why?
They: Because the project manager had been working for him as extern for 4 or 5 years and was still being spoken with "Sie"
I suppose I got his respect exactly when I said "No" and then I gave him technical reasons to support my "No" some of them even protecting the machine or the ergonomy of the future operators of his company. I gave him even an alternative (that he payed extra, because was against was written in the contract)
So yes, learning when to say "No", being confident enough to say it and good enough to counter with objective arguments... is one of the worthiest thing that comes with experience
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: So yes, learning when to say "No", being confident enough to say it and good enough to counter with objective arguments... is one of the worthiest thing that comes with experience
Very
|
|
|
|
|
A long time ago I read somewhere that when writing software it takes 95% of the forecast time to do 95% of the work and another 95% of the forecast time to do the remaining 5% work. Whenever the PM insists for estimates on task duration I make a generous estimate and double it.
|
|
|
|
|
Back in the day I did mine with factor 1,5 if I had a really good project description and I did my own chats with the customers. A 2,5 or even a 3 when I had bad specs or no first hand information.
My boss still added a 50% more, so he could bargain with the customer up to 25% down and still have his own buffer.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Male ego? I think it would be better to write "ego" without a qualifier.
Sorry for my bad English
|
|
|
|
|
I've always been a fan of saying "no" when it's needed. As long as it's done the proper way, I find it only helps with planning and actually improves your professional image in the eye of your counterpart.
Well, managers are often an exception to that rule, alas!
A few years ago I had a particularly funny (though it was NOT funny for me at the time!) eexperience: a big client's PM called me to discuss the schedule of a rather big project. She sent me the whole planning and we went through all the deadlines and discussed in detail all activities. In the end, it was a demanding schedule, but not impossible. I was positively surprised, and agreed that it was doable.
That's when I commented on a date for a meeting: I was not available on that specific day. She told me to ignore the dates on the schedule... I said "what?". She said yeah of course the schedule was about the time it would take to complete the project, but the date on the schedule were all off: the project would start the next day instead of the next month...
Let's just say that I answered with something more... articulate than a simple "no"
In theory, there is no difference between theory and practice, but not in practice. - Anonymous
A computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. - B. Bryson
|
|
|
|
|
I never understood why people are so tied up in dates. Understanding dependencies is better for everyone, and just simpler.
"Here are the things we need to happen before X. Whenever those things are in line, we can start work on X."
You know, the basics of iterative development.
It's even o.k. to give a rough timeframe for X (assuming it's reasonably well-defined, or the business people understand and buy into it being rough). But that doesn't define a date from now, it (roughly) defines a date from start of X.
Good luck, Marc.
|
|
|
|
|
After 42+ years of working in corporate development both as an employee and a consultant, I retired.
It wasn't the changing technologies but simply the fact that I couldn't work for assholes any longer...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outklook.com
|
|
|
|
|
Same here. we had a PM pushed on us recently, and wanted break downs for every step on every project with completion dates for each step. That was a solid no from us also. there are just two of us devs at our community college, not only do we have daily tickets, a backlog of apps to fix, upgrade, or create we also now have a new data store/schema coming from the state that we have to migrate to in the next year.
With everyone working from home, i understand they want some sort of metric on our day to day to make sure things are getting done, but this is not the way. things change too much from day to day. like the other day I got everything cleared away to get back to working on an upgraded app; 2 hours in everything got derailed when an emergency came in that used up the rest of the day.
I've been told in the past (different PM), if you know how long it takes to put a button on the screen you can estimate how long to do everything else. everyone who has actually done software development, can give educated guesses like that feature might take 3-4 days, but actually takes 1 day or 1 week, but don't hold me to the educated guesses especially when other things popup. Same PM told me all programming is simple; it's just 'click,click,click'
I've been doing Dev work for over 20 years now and have not missed a deadline yet, and all without any PM. PM's should be there to organize information and keep all parties updated, and a source to dig up information needed, but please putting a measurement on dev's productivity with dates is dumb, might as well go back to KLOC measurements, absolutely meaningless, since I could say that feature will be done in 6 months finish it off in 3 hours and take the rest of the time off.
|
|
|
|
|
Aaaand another developer is labelled a Prima Donna that is hard to work with. Heavy sigh.
Ok, yes, you should say, "No" sometimes. As a developer that wants to be helpful and driven by a sense of purpose, it is hard to say, "No". I've erred more on the optimistic side by saying, "Yes" and then having to work heroically (ie late nights and weekends) to meet my commitments. Chalk that up to experience.
Instead of simply a one word answer that is perfectly realistic but not helpful, why not follow up with what you CAN do? Then list all your risks and unknowns so that the PM and the rest of the team can track them, revisit them each week until the risk is dealt with or the unknowns become known. If your worst fears are realized then you look like a prescient genius. If not, no one will bother to remember.
A good PM will not simply manage the schedule but will also manage the risks and unknowns. The PM will help to develop contingency plans, re-negotiate the schedule and resources, and escalate issues that are blocking you or other team members to keep the project on track so you can focus on the technical issues. The PM can only succeed if he/she has good info to manage the project and depends on the technical folks for that information.
A bad PM will only manage the schedule and hold everyone to the earliest date ever uttered by anyone at any time based on any assumptions. So, document your risks and unknowns along the way for the post mortem, err, uhh, retrospective.
Keep your friends close and your PM closer.
|
|
|
|
|
Shmoken99 wrote: A good PM I never met a single one in 40 years of IT. Admittedly a couple were not that bad.
|
|
|
|
|
Today in 1858: The first Transatlantic Telegraph Cable was Completed.
And then there was communication, but still no TCP/IP.
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
JUST ARRIVED STOP MERCANS WEIRD STOP WTF OMFG LOL STOP
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Not Oscar Wilde's most eloquent tweet.
|
|
|
|
|
Still more eloquent than most tweets ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
theoldfool wrote: And then there was communication data transfer
Reliable communication still doesn't exist, e.g. men still don't know what women really want.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: what women really want Speak for yourself, but I can give you a hint: No matter how much they have, it`s always that what they don`t have.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
CodeWraith wrote: No matter how much they have, its always that what they don t have.
It can't be that simple; most men want the exact same thing.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
The big difference is the way they try to get these things.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
CodeWraith wrote: No matter how much they have, it`s always that what they don`t have.
Can confirm. Works that way with me, too.
Real programmers use butterflies
|
|
|
|
|
men still don't know what women really want
It isn't us.
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
theoldfool wrote:
men still don't know what women really want
It isn't only us. FTFY
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Daniel Pfeffer wrote: men still don't know what women really want That not the half of it.
The real problem is that women DO know what men want and make full use of that knowledge!
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Transatlantic?
So does that mean it was originally built over the pacific but switched later on?
|
|
|
|