August 7, 2017 at 9:05 pm
Comments posted to this topic are about the item What's Your Approach?
August 8, 2017 at 12:48 am
Looking back on all the projects you've delivered (yes, talking only about successfully delivered ones), how good was your initial estimation of the effort, knowledge, skills required for its completion?
And if you'd have a correct estimation on the beginning of any of the projects - how many of them would you dare to commit to?
Can remember any?
🙂
_____________
Code for TallyGenerator
August 8, 2017 at 12:58 am
Why not CUD without lying? I stood up many a time saying I don't pretend to understand everything right now, but anything is possible and it sounds like an x day project. Yes, you do put yourself under a lot of pressure and a few times I had to go back and change the deadline or increase the resources, but that did not happen a lot and it kept management happy. 🙂
5ilverFox
Consulting DBA / Developer
South Africa
August 8, 2017 at 1:28 am
I guess the answer like SQL is - it depends.
If the PM is good enough and has enough insight they won't commit to some flight of fancy, but they will commit without necessary understanding all the details.
The main problem is about how the customers/stakeholders expectations are set.
IT projects are not like life as the editorial alludes IMHO. If you agree to wild requirements without understanding then if your team succeeds in delivering it then they have also succeeded in adding a tonne of technical debt. Sooner or later it will catch up with you and something will explode.
August 8, 2017 at 2:46 am
Japie Botma - Tuesday, August 8, 2017 12:58 AMWhy not CUD without lying? I stood up many a time saying I don't pretend to understand everything right now, but anything is possible and it sounds like an x day project. Yes, you do put yourself under a lot of pressure and a few times I had to go back and change the deadline or increase the resources, but that did not happen a lot and it kept management happy. 🙂
I see exactly what you are saying.
Honestly, I think I have just started taking such calculated risks, with being honest up front to try my best; rather than committing that I will.
August 8, 2017 at 2:51 am
Sergiy - Tuesday, August 8, 2017 12:48 AMLooking back on all the projects you've delivered (yes, talking only about successfully delivered ones), how good was your initial estimation of the effort, knowledge, skills required for its completion?And if you'd have a correct estimation on the beginning of any of the projects - how many of them would you dare to commit to?Can remember any?:-)
With regards to the estimates, I have hardly delivered anything on time. That was because:
1. Requirements changed
2. Devil in the Detail took longer to kill.
I would say if I had known everything front, I would have hardly committed.
I must confess, I now see your point and completely take it. The fun (or challenge) of not knowing the unknown is what makes us brave; and keeps the work exciting.
August 8, 2017 at 3:22 am
Just to stay in accord with the general vibe here, I think you do need to commit without working out every detail. Essentially the full UCD is the waterfall model. What we found in that model is that it made clients unhappy because it didn't allow for the necessary changes which would need to be undertaken because of the unknown unknowns.
What we try and do nowadays is to plan for what we are doing to change somewhat as we go along and make provision for that in the plan. Still, it's easier said than done. What you don't want to do is fail to understand necessary major functionality, as that will put you into a weak position. What you can do is refine and perfect carefully as you go along.
We don't lose or wildly get projects wrong really here now with this approach - but I'd say we are 70% UCD and 30% CUD if asked to provide an approximate balance.
August 8, 2017 at 3:25 am
call.copse - Tuesday, August 8, 2017 3:22 AMJust to stay in accord with the general vibe here, I think you do need to commit without working out every detail. Essentially the full UCD is the waterfall model. What we found in that model is that it made clients unhappy because it didn't allow for the necessary changes which would need to be undertaken because of the unknown unknowns.What we try and do nowadays is to plan for what we are doing to change somewhat as we go along and make provision for that in the plan. Still, it's easier said than done. What you don't want to do is fail to understand necessary major functionality, as that will put you into a weak position. What you can do is refine and perfect carefully as you go along.
We don't lose or wildly get projects wrong really here now with this approach - but I'd say we are 70% UCD and 30% CUD if asked to provide an approximate balance.
VERY WELL SAID. Thanks
August 8, 2017 at 5:42 am
Branson refers to 'an amazing opportunity', and not specifically to a project.
When I first read that quote, I read it as a new/different job opportunity, not something as limited as a single project. And in a new role, the deliverables are less clearly defined and there's more chance of making it a success, IMO.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
August 8, 2017 at 6:49 am
In my humble opinion, I guess both approach are OK, but in real life nothing is black or white, everything is in gray scale (my partner used to said that). Some times each one would be for me the right option
August 8, 2017 at 6:51 am
Richard Branson was talking about personal commitments. Don't ever be like the sales guy at my first company who committed one of my fellow programmers to work on Thanksgiving just so he could get a client to "yes"!
August 8, 2017 at 7:03 am
There does need to be a balance. You will never know the entire time cost of a job ahead of time, but with experience you can pretty much tell what will be the easy and the hard parts.
Sometimes a degree of honesty is helpful. Give the client a range, and explain where the trouble spots are likely to be. The fact that you can pick out the trouble spots ahead of time may even give the client more confidence in your judgement.
...
-- FORTRAN manual for Xerox Computers --
August 8, 2017 at 7:17 am
To me honesty is always the best policy. It's always about setting expectations and not 'playing games' to get the client on board. Sure you can take calculated risks but in doing so you also set boundaries/parameters to work within to contain those risks. As long as this is clearly defined and understood by all parties involved there should be no surprises that can't be handled.
When I was working independently and I had leads with new clients, I would frequently be asked to do work I hadn't done before. I would be honest with the client and let them them know that X was new to me. I would offer an exploratory period where I would, to some degree, prove that task was doable by me or we wouldn't move forward. I never had a potential client say no to this and I never was not able to get the job done.
I was honest, I set boundaries to limit the risk and I set expectations. It works.
August 8, 2017 at 7:27 am
As when an auto mechanic says 'the radiator is bad, but once I'm in there I will need to check the water pump as well'. Let the customer understand ahead of time where the variability is likely to occur.
...
-- FORTRAN manual for Xerox Computers --
August 8, 2017 at 7:46 am
Firstly, I agree with Phil, Branson's cited quote dealt with personal opportunities, not projects. So to a major extent, the quote is out of context as far as project management goes. But, given the typical customer response, they prefer to hear "yes" to requests. My mentor said it like this, "Learn to get smart quick if you don't know anything about it." With 40+ years as project manager/director/implementer I usually will say "Yes, it can be done, but given the risks and unknowns the timeline will be between n to x days (or weeks, or months)." Often meeting a deadline in a project plan depends very much on the quality of the team in conjunction with the project manager's effort estimating ability. In other words, I nearly always commit, but my time frame can become very fuzzy depending on the request.
Viewing 15 posts - 1 through 15 (of 26 total)
You must be logged in to reply to this topic. Login to reply