Define IT Project [Part 1/2]

Sounds simple ? Not at all.

If you are reading this post, you’re probably familiar with IT Projects. But what’s an IT Project?

One needs to have this question in mind, in order to fully understand why communities and IT Services DAOs will be at the heart of the “Future of work” revolution.

It’s probably the main reason why I love this question above all others. Also, I really make people laugh whenever I provide an answer for it. 100% of the time.

Do you really know what’s an IT project ?

Hint 1: Wikipedia is always a good start

A project is any undertaking, carried out individually or collaboratively and possibly involving research or design, that is carefully planned (usually by a project team, but sometimes by a project manager or by a project planner) to achieve a particular aim. An alternative view sees a project managerially as a sequence of events: a "set of interrelated tasks to be executed over a fixed period and within certain cost and other limitations".[2] A project may be a temporary (rather than permanent) social system (work system), possibly staffed by teams (within or across organizations) to accomplish particular tasks under time constraints.[3] A project may form a part of wider programme management[4] or function as an ad hoc system.[5] Note that open-source software "projects" or artists' musical "projects" (for example) may lack defined team-membership, precise planning and/or time-limited durations.

(source here)

Hint 2: I have a way more accurate definition

This is how I like to describe an IT Project when speaking to my students or children. You can also see it as my ultimate take on explaining what I do during family dinners.

An IT project is a project between:

• someone who does *NOT* know what he wants and

• someone who does *NOT* know what he does.”

If you work in IT, you may probably have already faced a similar situation. Sounds familiar ? You actually can tell when no one knows - that’s when people in charge of your project look like this:

There a few logical reasons that can help explain this reality :

1. You’re viewed as the “expert” by your customer (and by law!)

2. Learning implies mistakes

3. Doing something implies uncertainty (any kind of project)

4. Zooming to an atomic level does NOT solve this uncertainty issue

We’ll also provide a few examples to illustrate what we’re talking about here.

#1 - You are viewed as the “expert” by your customer (and by law!)

Your customer probably doesn’t know much about what to expect from your field of expertise. Otherwise why would he ask you to do this project? His level of maturity could sound like “I want a nice website”.

And you probably don’t know that much (yet) either about what you’ll deliver for him, or how you’ll actually do that. Simply because no one knows everything (and being aware of its own ignorance is quite a good step ahead :-)).

Put it another way : KPIs for success are rarely known upfront… “Define Success*” (*we’ll tackle this in another blogpost)

All this is tightly related to a few other challenges like Denial of Reality*, Intercultural Differences Management*, Team Situation (&Risks) Awareness* & so on.
(**also other blog posts)

—

In this respect, you'd better try to understand your customer (and also his end customers) and create a high-level of proximity and confidence, because the contrary simply won't happen.

And if you don't do this: how could you be able to understand his risks, draft a contract accordingly and more importantly, ensure the whole project is perceived as a success?

#2 - Learning implies mistakes

This is true for a human-being, but also at an organizational level which can been seen as a living organism too. If you have some time, this conference about holacracy is inspiring :

The main point explained here, is that whatever the level of control you’re trying to apply, mistakes or conflicts will happen anyway. The only difference will be: either you are aware of them (by encouraging transparency) or not (by blaming it).

So, instead of imagining lots of sorts of penalties in your contracts, and spending a lot of time & energy controlling what’s happening, you'd better make it happen and encourage collaborative governance, risks prevention and a conflict resolution process.

#3 - Doing something implies uncertainty (any kind of project)

This is true for anything. Really! For example:

Cooking a new recipe

• Imagine you need to prepare a meal for your friends.

• At first, you don’t know yet what to cook (or how to cook - but this is another problem :-)),

• Then you decide and choose one recipe,

• Then discover what needs to be bought vs what you already have,

• Then discover how to cook it,

• Then you make some mistake, it was almost ready, but you need to do it again

  and you don’t have the ingredients any more.

• You need to go to the grocery store again & buy some more stuff.

And the list may go on and on… Until you reach the point when you know exactly if the meal is ready!

Any timeline before this point is only a guess with some given level of uncertainty. However (as seen on Wikipedia), your IT project is part of something bigger and customers need visibility - aka deadlines - in order to organize everything else.

This is one of the key paradoxes in IT Project which often sparkle conflict and burn-out (SNAFU for our US friends & readers).

One of the solutions suggested by our developers & agilist friends is called #NoEstimates. (#NoEstimates is often related to #SoftwareCraftmanship as well).

There is still a lot of fuss on #NoEstimates methodology on Twitter or LinkedIn. You know the drill → soon in a Skilld blogpost.

#4 - Zooming to an atomic level does NOT solve this uncertainty issue

Atomic Design methodology is quite common in web design. Basically you define the smallest design elements (atoms) and start building scaling them to molecules, organisms templates and pages :

Atomic Design principles - copyright Bradfrost.com

It looks great but is incredibly difficult to implement because you never know from the very beginning what are the kind of atoms you will need…

Besides this, having defined the atoms does not tell you how to manage them. Meaning there are still a lot of different ways to implement them. (aka uncertainty, again).

Somehow, uncertainty can be considered as a continuous space as well.

Said differently, even if you downsize to the smallest design object, you will not suppress the uncertainty totally!

—

A situation you may face when managing IT projects: you can try to isolate and distribute atomic responsibilities, but it will still be rather difficult to enforce it at the operational level, and it will either hard to interpret, or a multi-tenants responsibility.

For example: if a developer had logged 3x more time than expected it could mean:

• That your estimate was wrong

• That the specifications were unclear

• That there was some mistake in time logged

• That the developer over logged

• That the communication level was inaccurate, either to low (lack of context) or too high (lot of time spent)

• That he was not skilled enough for this task

• That the work distribution algorithm is not efficient

• That he had a last minute coding surprise like your meal cooking

• And so on…

So beware of the over simplified interpretation before blaming someone!

—

A few other simple examples to highlight the topic

1. I am rich and want my dream house built.
   My dream = a “beautiful & mainly purple” house. (Why not?)
   Now imagine you are an architect and this is a small project for you, so that you give it to your 6-month intern who will need to translate my dream into blueprints & tasks? Now you have a typical project.

2. My website is outdated.
   I want to create = a new website “exactly as the old one” - LOL (Obviously a few things should change if it’s new). I give it to a fairly young web-developer (not too expensive) and he will work on this nice project. Great, this is now another typical project.
   

3. Onboarding & Lack of awareness
   Some newbie in your organization is about to work on your IT project, but he is not yet fully aware of all the Onboarding topics he should learn. (nb : are you ever fully aware in an ever changing environment?) This is another typical use case.

This one is related to the level of trust we described in a previous post.

1. “Hill Charts” by Basecamp is a good example to showcase uncertainty. Basecamp has done a great job trying to fix all the challenges we are facing with agile IT Projects. You can visit their website & all their methodology blog posts which are great. One of them, called “Hill Charts”, is great at making uncertainty explicit.

Hill Chart of uncertainty - Copyright Basecamp

They use it as a tool to show the progress of the tasks of a given project.

—

Conclusion

Ok. All of this sounds great. I got it. Now I know what’s an IT project !

No no not yet. Dear reader, this is only the beginning…

—

Do you really want to know what an actual IT project is?

If we’re being realistic, the kind of projects we handle are far more chaotic than the examples above.

A real-life IT project is a project between:

• A lot of people who do *NOT* know what they want and do *NOT* agree and

• A lot of people who do *NOT* know what they do *NOT* agree either.

Ah… what a relief ! At least now we’re much closer to reality. Now that we’ve admitted that few people know what’s going on in IT projects are complex, it’s time for a sum up.

Tackling the right challenges in IT Projects

We like to think that a problem well defined is halfway fixed. So I tried and listed 5 recurring challenges that occur while managing in IT projects. In the 2nd part of this blog post series, we will go deeper into each challenge, and see what can be done to face them.

KPIs are misaligned, sometimes unknown

Business rarely understand tech capabilities, nor consider their own dynamic organization

Learning implies mistakes, but blaming is the golden rule

Uncertainty is certain, but visibility is needed nevertheless

Responsibility can not be fully distributed into clear roles

That’s it folks! Part 1 is over, and Part 2 is now available here:

Define IT Project [Part 2/2]

To be continued…End of part 1

---

As usual: If you are interested by all these topics and want to reach out, you are warmly welcome to contact us, either on LinkedIn (here or here ou here), or directly on Skilld.cloud