Cloud based web sites - Alfa Romeo Forum
You are currently unregistered, register for more features.    
The Technology Section A place to discuss technology & gadgets.

 
Thread Tools
(Post Link) post #1 of 6 Old 17-10-12 Thread Starter
Status: -
Unregistered
 
Join Date: Dec 2010
Location: United Kingdom
County: Lancashire
Posts: 57,288
Hmmm Cloud based web sites

I need help folks

Today at our group H&S meeting I was "nominated" as the person who is going to create our group HS&E cloud based web site

Our MD is an iphone fanatic and want's the board and all of the senior management team to be able to access a cloud based site that links all three plants HSE information via iphones and pads.

I have a few idea's about content and I will have support of our IT Dept so it's not like I'll be doing it alone.

It's a really pro active move on his behalf and I'm pretty chuffed that I've been asked to do it.

So can anyone give me some tips, so I don't look like a complete numpty when I talk to the IT Boffins

Also, it's going to be apple devices so no negotiation or off topic android this is better than that app please

I know I have a reputation for crap jokes and general mischief but can we keep this thread serious.

Stay Safe
Tony

Last edited by Happy Man; 17-10-12 at 22:44.
Happy Man is offline  
Sponsored Links
Advertisement
 
RSK
Status: - Update
Guest
 
Posts: n/a
Hi HM,

Do you want or a site which users navigate or do you just want a place in the cloud where you can store docs relevant to your sites and procedures ?

RSK
 
(Post Link) post #3 of 6 Old 18-10-12 Thread Starter
Status: -
Unregistered
 
Join Date: Dec 2010
Location: United Kingdom
County: Lancashire
Posts: 57,288
RSK We have a brilliant intranet site at our plant that works well for all departments but the other two plants don't have anything nearly as sophisticated.

So rather than build two more intranet sites at the other plants the intention is to build a group site and host it on a cloud, we would need an area for document storage and an another lounge/area for R&D to delevop new features before we launch them on the main site.

But the primary function would be a site that can be easily navigated where all the management team can see plant stats, KPI's, best practices.

Like I say the initial site will be a three way hook up of the EH&S departments at the three sites and grow it from there
Happy Man is offline  
Status: -
Newbie
 
Join Date: May 2011
Location: United Kingdom
County: Hampshire
Posts: 5

Member car:

Nowt :(

No idea what kind of stuff you're usually up to, and where I worked we ran customised versions of our software for clients so it was just 'old-fashioned' SaaS rather than Cloud-based, so sorry if this comes in as too obvious or something...

Maybe its just me, but what I'd suggest is that you focus on what you need it to do rather than start going on about cloud or whatever method of putting it together if you've not spoken to the IT team yet; depending on how your IT Department feel, it may turn out that they'd rather do the workings of it differently.
Every time I've seen clients get too focussed on the how instead of what and why, its wasted loads of time.

Essentially, sounds like you've got a reasonable grip on the requirements to start with, which is the main thing.

You need to know as accurately as possible what you're going to actually be using the site for & how it fits into the regular work you do. Once you've got that figured out, the next thing will be sitting down with the IT guys & figuring out what you actually need from the site, as some things may not map directly across from what you have now - I've seen weeks wasted because the client wanted a button that did X, just like their old system. While the equivalent button on ours did X,Y and Z - they were so insistent nobody sat down and said "look, do you need the intermediate steps for some reason?" until it came to us making it and we said "did nobody suggest they use the button we've already got? Its better and its already there..." and the project manager and the analyst suddenly went quiet... They then pointed out the standard setup, and the customer thought it was the best thing since sliced bread.
Don't worry about look and feel too much until you actually have the requirements sorted out, as obviously its dependent on that.

As you're doing it in stages make sure its very clear what each stage contains & what stuff is interlinked - also make sure you're prepared for what happens if certain features aren't going to be ready for a particular stage - does it mean that if you don't have X ready on time, you delay the release until its ready or do you push the feature back to the next stage?

If the IT guys suggest something that comes across as a silly suggestion, make sure you ask why they've suggested it, don't just go "no" - ask why they suggested it. It may turn out they're asking it for a reason other than just not getting it (for example, to avoid running into a limitation of some framework they're planning on using, or something like that), so asking can avoid a whole lot of trouble.

Learn how the IT guy you're dealing with does his estimates when you're figuring out the deadlines. This is probably a bit better than I'm used to as its an internal team rather than using an external company where you can end up with a project manager who's happy to promise things to happen immediately and take a day that the technical team will look at and go "no. That'll take a week and we can't start till Tuesday because X needs to be done first" . Most people will figure out a rough timeframe and add a little extra just in case things go wrong, though this varies a lot based on how optimistic the people you're dealing with are (my old boss had a really bad habit of giving best and worst case then promising the best-case, so it looked like stuff was late 75% of the time instead of early 25% / on target 75%). In which case, be aware of the best and the worst case, and assume that if it can go wrong it will so don't get suprised when someone says "it'll be sometime this week, probably wednesday to friday" and it turns up Friday afternoon not Wednesday.
Leave plenty of overrun time in the schedule and don't try and squeeze in "one more thing" if it looks like you're on-time unless you know for sure its a very minor thing because sods law says that one thing will always be a nightmare; use the time for extra testing instead.

Also, don't push for stuff to be delivered if you don't even know what it is you need delivered yet. Sounds crazy, but you hear a lot "oh we need it by tuesday"... "what do you need exactly?" ... "dunno..." - figure it out, then do it. Saves wasting time, actually gets you it faster.

When you're testing out prototypes and such, if someone goes "we need to bring it down to make some changes", try and be flexible, and allow for overruns. If they say it needs to go down for say 3 hours don't push hard on the limits of that. I've had situations where project managers have gone "oh, they need that test system - we can only have it down for 2 hours", when it takes 6 hours to run the upgrade script...

Sorry if that's pretty general stuff - I've not actually been on the analysis side, but while I've been speaking to customers to clear up some complete messes of specs for customisations, builds, upgrades etc. I've been given, that's the kind of repeat problems I used to see.
Pockets is offline  
Status: Broken again...
AO Platinum Member
 
GhostyDog's Avatar
 
Join Date: Sep 2005
Location: Right Side O The Pennines
County: West Yorkshire
Posts: 25,672
Tony, give me a call to discuss, I've implemented exactly this type of service before.
GhostyDog is offline  
(Post Link) post #6 of 6 Old 19-10-12 Thread Starter
Status: -
Unregistered
 
Join Date: Dec 2010
Location: United Kingdom
County: Lancashire
Posts: 57,288
Quote:
Originally Posted by Pockets View Post
No idea what kind of stuff you're usually up to, and where I worked we ran customised versions of our software for clients so it was just 'old-fashioned' SaaS rather than Cloud-based, so sorry if this comes in as too obvious or something...

Maybe its just me, but what I'd suggest is that you focus on what you need it to do rather than start going on about cloud or whatever method of putting it together if you've not spoken to the IT team yet; depending on how your IT Department feel, it may turn out that they'd rather do the workings of it differently.
Every time I've seen clients get too focussed on the how instead of what and why, its wasted loads of time.

Essentially, sounds like you've got a reasonable grip on the requirements to start with, which is the main thing.

You need to know as accurately as possible what you're going to actually be using the site for & how it fits into the regular work you do. Once you've got that figured out, the next thing will be sitting down with the IT guys & figuring out what you actually need from the site, as some things may not map directly across from what you have now - I've seen weeks wasted because the client wanted a button that did X, just like their old system. While the equivalent button on ours did X,Y and Z - they were so insistent nobody sat down and said "look, do you need the intermediate steps for some reason?" until it came to us making it and we said "did nobody suggest they use the button we've already got? Its better and its already there..." and the project manager and the analyst suddenly went quiet... They then pointed out the standard setup, and the customer thought it was the best thing since sliced bread.
Don't worry about look and feel too much until you actually have the requirements sorted out, as obviously its dependent on that.

As you're doing it in stages make sure its very clear what each stage contains & what stuff is interlinked - also make sure you're prepared for what happens if certain features aren't going to be ready for a particular stage - does it mean that if you don't have X ready on time, you delay the release until its ready or do you push the feature back to the next stage?

If the IT guys suggest something that comes across as a silly suggestion, make sure you ask why they've suggested it, don't just go "no" - ask why they suggested it. It may turn out they're asking it for a reason other than just not getting it (for example, to avoid running into a limitation of some framework they're planning on using, or something like that), so asking can avoid a whole lot of trouble.

Learn how the IT guy you're dealing with does his estimates when you're figuring out the deadlines. This is probably a bit better than I'm used to as its an internal team rather than using an external company where you can end up with a project manager who's happy to promise things to happen immediately and take a day that the technical team will look at and go "no. That'll take a week and we can't start till Tuesday because X needs to be done first" . Most people will figure out a rough timeframe and add a little extra just in case things go wrong, though this varies a lot based on how optimistic the people you're dealing with are (my old boss had a really bad habit of giving best and worst case then promising the best-case, so it looked like stuff was late 75% of the time instead of early 25% / on target 75%). In which case, be aware of the best and the worst case, and assume that if it can go wrong it will so don't get suprised when someone says "it'll be sometime this week, probably wednesday to friday" and it turns up Friday afternoon not Wednesday.
Leave plenty of overrun time in the schedule and don't try and squeeze in "one more thing" if it looks like you're on-time unless you know for sure its a very minor thing because sods law says that one thing will always be a nightmare; use the time for extra testing instead.

Also, don't push for stuff to be delivered if you don't even know what it is you need delivered yet. Sounds crazy, but you hear a lot "oh we need it by tuesday"... "what do you need exactly?" ... "dunno..." - figure it out, then do it. Saves wasting time, actually gets you it faster.

When you're testing out prototypes and such, if someone goes "we need to bring it down to make some changes", try and be flexible, and allow for overruns. If they say it needs to go down for say 3 hours don't push hard on the limits of that. I've had situations where project managers have gone "oh, they need that test system - we can only have it down for 2 hours", when it takes 6 hours to run the upgrade script...

Sorry if that's pretty general stuff - I've not actually been on the analysis side, but while I've been speaking to customers to clear up some complete messes of specs for customisations, builds, upgrades etc. I've been given, that's the kind of repeat problems I used to see.
Thanks for taking time to write such a detailed reply

I think as a team we understand what we would like it to do, now as to if that is what the directors want is a different matter

It's a pilot to try to standardise the information sharing and communication across three site and all completely new to me so doubtless I'll be back to this thread over the next few months

Quote:
Originally Posted by GhostyDog View Post
Tony, give me a call to discuss, I've implemented exactly this type of service before.
PM sent mate
Happy Man is offline  
Reply

Go Back   Alfa Romeo Forum > Misc Lounges > Community Discussions > The Technology Section

Tags
based , cloud , sites , web

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page



Posting Rules  
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off

 
For the best viewing experience please update your browser to Google Chrome