Building an ICT strategy - Intro to my framework

[emp]

Alright, so some background info:

As some might know, I hold a 9-5.
I also hold the opinion that not every 9-5 is bad, but I am not flipping burgers.

So here we go for some chest-thumping

I am head of the ICT (Internet, Communications and Technology) department at a think tank's project.

I am not going to link it here, and will remove it if someone else post the info.
Nothing I am ashamed of and I will tell you on Skype or per PM if you ask nicely. Just don't want it linked on WF.

I trust that you can figure it out anyhow.

In our web development, we are dealing with a site that has

• PR of 7
• 730K indexed pages
• original content that has grown over 15 years
• a partner network of 230 organizations
• custom seach engine
• Proprietary Knowledge Management System
• Frontend based on eZ Publish CMS
• Blog uses WP

:338:

We are also responsible for 30+ related websites, technical support, internal tools such as our CRM, timelog, etc..

Did I mention the team is now 4 people and we operate on this budget --> :2twocents:
Yeah, baaaalling! :cool-smiley-008:

So planning and strategy get to be of some importance.
I am writing this down and adding a section to each building block on how this might be of use to you.
As strategies go, they allow you to do a "top-down" planning. The building blocks are HUUGE, but I can derive projects and tasks from them and use the whole thing to develop the big picture.

Does this work?
Well, we never had better numbers (unique visitors, pageviews) before and I managed to severely reduce the budget ICT uses.

So, no further ada, my planning framework looks like this:

Obvious management presentation PPT

Stable IT Platform
This is the central importance (duh!)
While this might seem trivial, it involves things such as server setup, maintenance contracts, data backup, etc...

One big step we took here was to move everything on a virtual server platform, and as such getting rid of our (often dated) hardware and the need to set up everything by hand / do physical (!!) maintenance)
--> 44K$ savings per year in hardware alone

Next year is going to be more cleanup, moving all sites (including small partners) onto LAMP and virtual environment.

What you can take away from this:
Look at your platform(s) including virtual and physical machines, tools that might be outdated / need upgrading or switching, hosting contracts, costs in general.

Clear Landscape
This might be seen as an extension of the stability issues, but in a grown environment, untangling dependencies takes on a life of its own.

In my work, this meant doing mundane things like listing all domains and sites, listing where data and sites reside (which servers), up to deciding which services can be deleted or are in need of a cleanup.

What you can take away from this:
Go through your list of projects and clean up, de-clutter your email and files, get rid of unneeded physical stuff and then organize and clear your view on your surroundings and future projects.

In another sense, this is the most "spiritual" building block, as it also serves as a tool for focus and alignment of projects.

Education
This is where I decide what individual team members (me included) andf the team as a whole need to learn and how we are gonna accomplish that.

For next year, this is HTML5/CSS3, mobile layouts, etc..
Our platform has to be ridiculously backwards compatible, so we are limited in this regard, but the developers also need something cool to work on.

What you can take away from this:
What do you need to learn in the next year?
How are you going to do it?

Innovation
This sits on the top of the pyramid, because it can only happen if the other blocks are there to support it.

Here we have things we want to do.

In our case, that is more multimedia and more interactive elements (PDF exports of collections of user-selected items), some new services and sites..

Some of these then play into the "education" section - as in "Oh, if we want to do X, we need to learn Y"

What you can take away from this:
What cool stuff would you like to develop next year? What businesses are you going to start, what do you want to improve?
Think about your goals and don't be afraid to add to your "education" section of planning.


OK, so much for now.

If you have more questions or feedback, please let me know.
::emp::

 

[Moxie]

 

[Moxie]

Just kidding, it sounds interesting.

 

[dzianis]

Very relevant to me personally, I'm at the point where "cleaning the landscape" is unavoidable if I want to move anywhere. Thanks for the post.

 

[Kiopa_Matt]

Thanks emp!

I'm curious, what do you guys do for structure / guidelines when it comes to future development. For example, you mentioned you'll be learning HTML5/CSS3 next year. How do you go about it?

Does everyone just go their own direction to learn it? Do you learn it first, then put together a training program / guidelines of some kind? Or you do all learn it together, then put together some general guidelines as to how things should be developed to keep some type of standardization throughout the projects?

In other words, what do you do to keep standardization within the development team / cycle?

 

[emp]

@Kiopa_Matt

Glad you liked it.

What you mentioned is one of the trickiest parts.
The list I gave above came hot off the press, so while I endorse all this, the budget and management buy in still have to be determined.

All in all, IT learning is always very self motivated, and apart from actually funding some training there is not a lot you can do.
Standardization for learning is impossible, as I am not sitting people in front of a test and get them graded. Where are we? high school?

So we have these options:

a) Official course - send the whole team to a training
b) Inofficial learning - We have this thing I call "Thinking Thursday" where I blocked one hour every week so the ICT team can sit together and discuss current projects in detail or talk about other interesting IT stuff.
We might use that time slot to disassemble some cool sites and see how they arrived at the solution they got to.

With option B, I will also have to see how we procure example pages and see if we can get some nice reading material for the team.

::emp::

 

[Kiopa_Matt]

Thanks again emp.

I'm more curious about structured guidelines you implement. For example, say commenting code. Is there a standard way of commenting code you expect everyone to follow, so developers can come in & out of projects easily? Or do you back off, give more leeway, and allow the team to comment code however they want? For another example, how about naming conventions?

This is the type of thing I'll be dealing with daily right away here, hence my questions. Where's that perfect balance between being structured & efficient, while still allowing people to do things their own way, making room for creativity and innovation. Know what I mean? You can't just have everyone doing whatever the fuck they want, but can't structure things so much that it impedes creativity. I would imagine it takes a bit of trial & error to find the right balance.

 

[amateursurgeon]

Don't fall into the trap of thinking you're "too small" to worry about this stuff yet. I spent a couple of days changing over to a new accounting system at the start of last tax year, and it has saved me dozens of hours that I can put into more productive things so far this year.

 

[emp]

@Kiopa_Matt

Ah... That is the sort of thing I don't do.
I will not micromanage people.

What I make very clear is that I expect them to comment their code and to use sensible variable names.

We also discuss meta-things like that in our team meetings and Thinking Thursdays in a relaxed manner. (Insert coder/geek humour here)

But the nature of our work requires us to work in a lot of different frameworks (Wordpress, Buddypress, CodeIgniter, eZ Publish,... just off the top of my head)

So devising a naming scheme that would fit in with ALL of these is madness.

We do a lot of commenting and also documentation on a wiki and I do hound my people for these things, but I do not micromanage naming guidelines, indentation schemes, etc..

::emp::

 

[emp]

OK, to add to that..

This IS a "feel your way in" thing, some coders need some more guidelines, others can just go ahead on very little specification. Key here is to check back with your people on how they are doing.

What I do is that I give people the benefit first, sometimes giving them too much freedom. I only gradually reduce and try to push again and again.

Example:
We had a new coder girl join us 2 years ago.
So the first project was worded something like.. Please adapt this team platform, just quick and dirty, make it look like our page a bit.

Check back 2 days later and the girl was absolutely clueless on what to do.

But... she was more than competent when it came to the technical side of things, but she was a person who needed more guidance.
So I wrote a quick description of all the tasks I wanted her to do, had the designer sit with me a bit and consult on colors and fonts and with that, she was able to do it just beautifully.

After that initial project, I always made sure she had the instructions she needed and slowly got her accustomed to more free-form work, where she could do things on her own terms.

She developed and was one of my top team members when she left, BUT she still needed closer guidance on bigger projects.

Other team members, you can basically say "Do this, make it look like that, kinda..." and they do great, but might not know all the technical details.

Key here is to know who can do what and who to pair up with each other.
Also encourage communication. Too easy for devs to hide behind their screens at times.

::emp::