Time Management

This section introduces some basic ideas and techniques for managing your time. It starts at a foundational level, with the basic question ‘what am I doing and why am I doing it?’ and tries to provide some tools to help answer that. Many of the tools and techniques in the Software Engineering Chapter are based on the ones introduced in this Section.

Understanding your Goals

An important part of time management is understanding your goals. This is not always a straight-forward thing to do, goals are informed by both organisational goals and your own career development goals. It may sound obvious, but the better you can identify and communicate what your goals are and how you hope to achieve them the more likely you are to acheive these goals. Conversely, not effectively communicating goals and strategies can lead to frustration for you and others.

Organizational Awareness

Goal formation and communication is closely related to organizational structure - the structure affects your ability to communicate, but your effectiveness in communication also affects the organisational structure.

[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
— Melvin E. Conway, How Do Committees Invent?

Fig. 7 shows a stereotypical ‘top-down’ organisational structure, where plans and timelines are formulated and dictated by leadership with little feedback from those doing the work.

Fig. 7 Sketch of a stereotypical ‘top-down’ organisational structure.

By contrast, Fig. 8 shows a ‘bottom-up’ structure, where those doing the work are involved in the formulation of work plans - collaborating with leadership and directly with other project stakeholders.

Fig. 8 Sketch of an idealised ‘bottom-up’ organisational structure.

The latter organisational structure has many advantages, those doing the work have more control over their time and workload, leadership are better informed on project details for decision making and have less burden on their time with fine-grained planning, and there is a greater tendency for knowledge-transfer within the wider organisation and with external stakeholders. As emphasised in Fig. 9, trust and communication are the two key differentiators in the project structures.

Fig. 9 There is a spectrum between a silo’d top-down organisational structute and a collaborative ‘bottom-up’ one based on levels of trust and communication.

In order to allow a beneficial ‘bottom-up’ organisational structute those doing the work need to effectively communicate what they are going to do and when and how they are going to do it. They also need to deliver on the plans they communicate, or else give timely and clear notice that they will be unable to do so. In the abscence of such information and trust then more onerous and likely less effective project record keeping and planning techniques are more likely to be used.

The next sections introduce project management techniques that can help you to formulate and communicate your goals. They are introduced in an abstract way, with real examples and tools introduced in later chapters related to Software Engineering.

Continuous Improvement

Continuous Improvement is a general, iterative framework for generating, communicating and acheiving long-term goals. Although not always explicitly stated, it is the basis for most modern project and time management techniques.

With reference to Fig. 10 Continuous Improvement amounts to:

• breaking complex, high-level goals into small steps (Plan),

• carrying out a small, manageable and measureable piece of work (Do),

• collecting feedback on the outcome of the work (Measure),

• learning from and acting on this feedback before taking the next step (Learn).

Put another way, this involves re-asking and answering the question ‘what am I doing and why am I doing it?’ frequently.

Fig. 10 Continuous Improvement is an iterative framework for time and project management

The following habits of effective groups are closely related to their adoption of Continuous Improvement ideas:

• Communication (especially documentation)

• Focus on Quality

• Teamwork and shared skillsets

• Automation focused

• Data driven decision making

• Bring Build-Measure-Learn feedback loops into processes

Although these ideas seem good on paper, and the basic idea is obvious, most projects and organisations do not adopt this way of working. The sketch in Fig. 11 shows one of the main reasons why. A common pattern in adopting new processes and automation is where after some initial enthusiasm a ‘trough of disillusionment’ is reached - requiring significant dedicatation to escape and to realise the potential of the change.

Fig. 11 Process improvement can be hard work, and if not seen through to completion can make things worse.

In the face of this ‘disillusionment’ it is easy to fall back to the comfort of time and project management patterns that do not follow this iterative and progressive approach, which emphasise short-term outcomes but which can make delivery of long-term goals and strategies more challenging. A similar behaviour, taken in the ‘trough of disillusionment’, is to introduce more process, or training in formal project management techniques (Agile, Prince) - which can feel good, like buying a book or gym membership - but without actually studying the book content or getting sweaty at the gym can just end up wasting time and money.

Summarizing the above, Continuous Improvement is a very simple idea but requires a lot of work to implement. There are many formal project management tools and techniques, introduced in the next section, but without understanding and buying into the most basic ideas of Continuous Improvement adopting formal techniques can end up doing more harm than good.

Project Management Techniques

As sketched in Fig. 12 the primary classes of project management techniques can be broken into:

• Agile: A structuted, iterative technique based on Continuous Improvement

• Waterfall: A structuted, sequential technique

• Ad-hoc: An unstructured technique, which might have iterative and sequential elements

Fig. 12 A sketch of the spectrum of project management techniques, from structured to ad-hoc and iterative to sequential.

In reality an actual project is likely to lay somewhere in this spectrum, with strict application of techniques like ‘Agile’ being rare due to the skills and discipline needed to enact them.

‘Agile’ techniques derive from Continual Improvement and Lean Manufacturing backgrounds - they emphasize communication and putting ‘people over processes’ in addition to the mentioned Continual Improvement preference for small steps and retrospection. As sketched in Fig. 13, DevOps and Platform Engineering movements have derived from the Agile movement. However, just as ‘Agile’ terminology has been widely co-opted to mean other things, so to have those terms.

Fig. 13 Agile project management is derived from continuous improvement ideas, from which DevOps and Platform Engineering ideas have further derived.

Waterfall techniques, sketched in Fig. 14, are based around the idea that a project must be planned in a high degree of detail and the plans agreed on by all stakeholders before work can begin. Ability to adapt or change are not emphasized - with the project being evaluated for success at a final ‘launch point’. Waterfall project management is correlated with top-down control of contributors’ work - a work-plan is presented in a rigid way that cannot be changed or improved.

Fig. 14 A sketch of the waterfall project management technique, where steps are carried out sequentially, only on completion of the previous one.

By contrast - an Agile project may focus on some form of limited or less feature-rich early launch with the aim of getting stakeholder feedback and improving on it in small steps over the duration of the project. The encouragement of ‘people over process’ promotes a ‘bottom-up’ structure in terms of how work is conceived and carried out. Contributors are empowered to change the project roadmap to bring in improved ways of working toward the project goals. To allow for this it is important that contributors have a basic understanding of how to manage a project by themselves, including how to determine the project scope and to break it down.

Use of Agile techniques in software have been associated with higher performing and happier development teams - however it is important to avoid the widely fallen for temptation to ‘cargo cult’ Agile processes (copy a process or ritual without thinking or understanding why you are doing it.) often sold via ‘Agile courses’ or frameworks. It is not possible to meaningfully implement Agile practices without first understanding and embracing Continuous Improvement as a fundamental tenet of it.XS

Subsequent sections of the handbook will introduce specific use-cases and tooling for project managment, building on the basic concepts introduced here.