July 20, 2015 at 8:22 pm
Comments posted to this topic are about the item There Are Always Constraints
July 21, 2015 at 5:47 am
What drives me bananas is when you explain repeatedly why something CANNOT happen, do your best to work around it given your constraints, and people keep asking you to do the same thing that cannot happen.
Where I work we don't own the network which myself and my boss have explained over and over but it never seems to sink in. The network has an unsecured wireless access and we are constantly bombarded with requests to implement wireless connectivity for various things. I keep repeating putting domain assets on unsecured wireless is a violation of every security policy there is, not to mention just being a Really Bad Idea.
There is a secured side, but getting access to that would require a domain migration to a domain we don't control and which also raises serious intellectual property and confidentiality issues.
I've begun asking people if they are willing to bet their paychecks on a data breach because that's what they're asking.
We certainly have to do the best we can given our limitations, but that works both ways. Staff and management have to understand OUR constraints and be willing to let us work within them.
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
July 21, 2015 at 6:33 am
If I have a serious enough issue with something, I always document it and what I feel it will cause to happen that will be bad for the project, group, or organization...and/or its customers.
That way if I think someone is making a decision that will ruin something and they try to say "well I didn't know" I can pull up the email and say otherwise.
If you have to live with some poor decision that you see as something that will burden, hinder, or ruin some part of the operation, it's best to document it and then move on with delivery within the design and scope of the requirements.
That way if something does happen, it's documented and the party who forced it can be held responsible...whether they're management or not.
July 21, 2015 at 7:01 am
That's why, when gathering and documenting requirements for a new project, it's helpful to also document separately what is Out Of Scope. Not only does it keep the development on track, but it also provides a glimpse of what could be, given more time, funding, or better technology.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 22, 2015 at 4:38 pm
Constraints are a fact of life, the difference between a good project and a bad one is prioritising correctly and that can only come from doing the research and understanding the business. AND then selling your ideas/advice. Unfortunately IT is not always good at this, perhaps because it is sometimes difficult to articulate or actually find someone interested in listening to all the reasons why they shouldn't do something a certain way, so don't tell them that, tell them all the good reasons why they should do it the best way. I like the "Out of Scope" idea, a taster for what could be , I call it Next Phase or job planning (if I don't have something else a client wants to spend on, I don't have a job) .
Absolutely agree that IT are sometimes so bound up in the next thing or what could be done that this sometimes blinds them to the Clients real priority , which is often time. Sometimes the basic's are needed fast, you can always revisit the project to enhance it later.
Where I have a real problem with constraints is where they put the bite on security. I have never been in a spot where this issue has lasted long. As soon as the problem has been explained properly the time/budget has been expanded to cover it. It perhaps helps that I work with smaller Insurance and Finance companies where a security breach would possibly put them out of business.
I think the point here is : Articulation and selling the good points. I.T. just needs to get better at selling..
July 28, 2015 at 7:55 am
Eric M Russell (7/21/2015)
That's why, when gathering and documenting requirements for a new project, it's helpful to also document separately what is Out Of Scope. Not only does it keep the development on track, but it also provides a glimpse of what could be, given more time, funding, or better technology.
The out-of-scope comment is a great idea. I think I'll share that today.
July 28, 2015 at 8:30 am
Iwas Bornready (7/28/2015)
Eric M Russell (7/21/2015)
That's why, when gathering and documenting requirements for a new project, it's helpful to also document separately what is Out Of Scope. Not only does it keep the development on track, but it also provides a glimpse of what could be, given more time, funding, or better technology.The out-of-scope comment is a great idea. I think I'll share that today.
I'm not sure if it's standard practice, but the requirement documents we have where I work, espeically for a large project, contains an "Out Of Scope" section. Typically this is a couple of paragraphs mentioning features that were discussed but were subsequently cut or deferred until a later release. With all the meetings and break room chat that occurs during the design phase of a project, it's a good idea to explicitly state what the developers should NOT be working on. Also, it's good to at least acknowledge some of the better ideas and let it be known that the first phase of development should be designed to accomodate with that future functionality in mind.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 28, 2015 at 11:15 am
From the article:
...or spent a bit more money (or time), ...
One of my goals is to stop spending money on "shiny new objects" and "cure-all snake oil products" that provide little ROI but continue to be championed by people that follow the tired old saw of "Just because you can do something in SQL Server, doesn't mean you should". It's also really difficult to get people to throw away that quarter million dollar "wonder product" even if people still "wonder" how to use it.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 28, 2015 at 11:54 am
Jeff Moden (7/28/2015)
From the article:
...or spent a bit more money (or time), ...One of my goals is to stop spending money on "shiny new objects" and "cure-all snake oil products" that provide little ROI but continue to be championed by people that follow the tired old saw of "Just because you can do something in SQL Server, doesn't mean you should". It's also really difficult to get people to throw away that quarter million dollar "wonder product" even if people still "wonder" how to use it.
Let me guess, your company purchased an MPP appliance?
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 28, 2015 at 3:39 pm
Eric M Russell (7/28/2015)
Jeff Moden (7/28/2015)
From the article:
...or spent a bit more money (or time), ...One of my goals is to stop spending money on "shiny new objects" and "cure-all snake oil products" that provide little ROI but continue to be championed by people that follow the tired old saw of "Just because you can do something in SQL Server, doesn't mean you should". It's also really difficult to get people to throw away that quarter million dollar "wonder product" even if people still "wonder" how to use it.
Let me guess, your company purchased an MPP appliance?
Heh... oh no... MUCH worse... WebMethods. Basically it's a super expensive version of SSIS, which I don't (and probably never will) use either. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
July 29, 2015 at 9:11 am
Jeff Moden (7/28/2015)
Eric M Russell (7/28/2015)
Jeff Moden (7/28/2015)
From the article:
...or spent a bit more money (or time), ...One of my goals is to stop spending money on "shiny new objects" and "cure-all snake oil products" that provide little ROI but continue to be championed by people that follow the tired old saw of "Just because you can do something in SQL Server, doesn't mean you should". It's also really difficult to get people to throw away that quarter million dollar "wonder product" even if people still "wonder" how to use it.
Let me guess, your company purchased an MPP appliance?
Heh... oh no... MUCH worse... WebMethods. Basically it's a super expensive version of SSIS, which I don't (and probably never will) use either. 😀
BWAHAAHAA.... WebMethods is more like SSIS, IIS, Windows foundation and F# got together and had a 1600lb baby. Who proceeded to swallow all of them whole....:-P
By the way - quarter million on WebMethods barely scratches the base license.... That shiny thing is going to cost quite a bit more.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
March 22, 2016 at 8:06 am
We must neither stop fighting the good fight nor let us be distracted when we get told to JFDI (Just Do It).
Our clients (whether figuratively speaking or actual) rely on our expertise so we must never give up telling them what we, as IT Professionals, believe they should know. It is their prerogative to ignore it.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply