Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • Project, Maintenance or Line Work - what is the difference and does it matter? | jimiwikman.se
    Jimi Wikman

    Jimi Wikman is an experienced and much appreciated consultant that have worked as team lead, scrum master and project manager for many years. He is also a popular work process designer and educator with a specialty in the Atlassian products. With more than 25 years practical experience as a frontend developer, graphic designer, tester and requirement analyst he knows the pain and pleasures of what the teams face on a daily basis.

    Project, Maintenance or Line Work - what is the difference and does it matter?

    Posted , 87 views, 0 comments ,

    Photo by Anna Shvets from Pexels

    If you work in IT, you have probably heard the words projects and maintenance many times. Usually it is in reference to different teams and organizations, but not always. Sometimes the same team can do both projects and maintenance, which can cause some confusion. To add to that confusion, you will sometimes hear the word line work as well. As these all see to be a bit malleable, it can cause some annoyance. With this article, I hope we can make a definition so we all know what we are talking about.

    These are all financial constructs

    Before we begin, let us define what these three terms refer to, since they are sometimes confused with processes or even methods. Projects, maintenance and line work are all financial constructs. This means that they exist as a way to manage budgets and resources. In most cases, projects and maintenance exist together and form sequential ways of working (waterfall, RUP and so on) while line work is the basis for iterative forms of working (Agile). This is also reflected in their financing where projects and maintenance mostly have fixed budgets and scope, while line work have fixed budgets, but scope is more loosely defined against value themes.

    Project

    A project is usually the easiest to define of the three. This is because most of the work in IT are still project based, so most people still work in projects. Projects are by their very nature sequential, meaning that they follow a step-by-step process to get funding and approval based on certain values. These values are often defined as features, but in some cases it can be other types of values. The difference between projects and line work is however that value need to be measurable and once set it normally can not be changed.

    Projects are defined as time limited bubbles of time, scope and resources that can span across different borders such as systems, organizations and even companies. When this happens, the project is split between the different areas and placed under an umbrella structure we call program. This makes projects the easiest form of financial structure to organize when you need to span multiple areas.

    Most companies that have been around a while also have a strong culture of organizing external resources around temporary work as projects as well. This is usually well-defined in their vendor management structure as well. This is why projects are the most common form of financial construct in most companies.

     

    Maintenance

    One of the most misused term of these three as it is often used for anything that is not project based. It also comes in two very different forms based on how contracts are defined in Vendor management.

    At its core, maintenance is nothing more than making sure the systems are working properly once a project has ended. This means that as a project ends, there will be a list of items that need to be taken care of, usually in the form of known bugs and technical debt. After the handover, maintenance handle unexpected incidents in production, problems and in some cases it also includes enhancements such as refactoring to make the system more stable.

    In some cases the maintenance get to work right after a release. This is when contracts are written without post go-live support, meaning that as soon as a delivery is accepted and released, the team in charge of the development no longer are responsible. This is often an awkward situation where the maintenance team and the development team can start to resent each other if there are a lot of incidents being released to production due to poor testing and acceptance processes.

    All of this is handled in a service management process that is matched against a contract with SLA and a budget for the work to manage the system or systems. This is often paid for by the product owner(s) or a business area within the organization on an annual basis, which is often managed through maintenance plans.

    Unlike project and line work, maintenance are not generating new value. The purpose of Maintenance is to maintain value, or to correct loss of value due to problems and incidents.

     

    Line work (line organization)

    If you have ever worked in maintenance where you also do development for new features as part of your work, then you are probably in some form of line organization doing line work. The term refers to a manufacture line where you continuously build things. Unlike a manufacture line, where you do the same thing all the time, line work in this context refer to continuous improvement when it comes to development.

    Line work, just like maintenance, usually have an annual budget. Unlike maintenance where the goal is to maintain value, line work have the same aim to produce new value in the same way as projects. In line work, however, this value is usually defined in terms of focus areas, or themes, and larger goals rather than defined ones as you have in a  project. This makes line work better suited for exploratory work such where value creation is iterated based on result.

    Line work often employ a flexible workforce, allowing them to quickly adjust resources based on need. This also works well for larger initiatives where the flexible workforce simply expand their numbers for a period of time and then shrink again. This however require a different way of handling vendor management and contracts as you can not define them around deliveries, but rather against value creation.

     

    The confusing mix

    It does not really matter what form your financial construct have, because at the end of the day you will adjust your preferred way of working anyway. You can work in an Agile methodology within a project and you can do waterfall in a line work setup. There will be challenges of course, but people do it every day all over the world.

    It is when things get mixed up you start to get problems. This usually happen with line work and maintenance, or projects and line work.

    Anytime you hear that maintenance also should so development of new features, then you are fading into a mixed situation, or are moving towards line work. This is confusing because you mix the concept of not generating new value in maintenance with creating new value as in line work, but without the flexibility in financing. This can cause headache, not just for managing the budget, but also because maintenance usually do not have a requirement process defined. The situation can be fixed however by moving over to a line work setup instead.

    The most common situation however is when projects try to mix fixed time and scope with exploratory methodologies. This is often done by implementing a sequential scrum methodology and an ad-hoc requirement process. Scope creep are very common and frustration high from confusing requirements and trying to iterate value within a confined time frame with fixed budged and deliverables.  The solution for this is usually to focus on requirements to reduce the ad-hoc situation and try to iterate withing the limitations presented in a more flexible way, rather than agile.

     

    I hope this helps

    As I see these terms used on a daily basis and sometimes in a very confusing way, I hope this definition helps. If you disagree with my definition, feel free to write a comment and we can discuss things. If you like this article, or better yet, find it useful, a comment or like is always welcome 🙂

    • Interresting 1

    User Feedback

    Recommended Comments

    There are no comments to display.



    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Similar Content

    • By Jimi Wikman
      As I am leaving the current project, due to the fact that I am leaving for another company, other people are taking over my duties and I get less and less involvement in the work that I used to hold together as the spider in the web.
      This is very difficult as I am used to be the one in the center of all things and now I am on the outside. The new team lead do things differently and the process of change always leave a residue of confusion and every fiber in my body just want to step in and "fix" things. 
      The thing is that there is nothing to "fix", it's just change and the fact that I no longer sit in the center of the project any more. The new team lead have things well under control and the project is doing just fine without me. 
      The realization that you really are not that important is both liberating an a bit sad. On one hand I am glad because it means that I have succeeded in making myself obsolete and the team no longer have need of my guidance. They work just fine without me following the processes and workflows we have built together.
      On the other hand I feel a bit like a parent no longer being needed by their children and they move from home. Just in reverse as I am the one leaving. It's a bit sad to realize that you will no longer be the one they come for when they need help or the one they turn to for advice and comfort.
       
      While this is a strange and sometime uncomfortable situation it is also a great opportunity to observe and learn from the new team lead and also to lift my gaze and look at things outside my part of the project.  It's quite interesting and it's a very good learning experience, especially when you can pick up on body language. I see so many things now that I have not yet had time to observe before and it give me a wealth of new insights.
      So I am in a position right now that feels a bit weird, mostly because I am not just leaving the project, but the company as well. It's also sad as I have to much time to think about how much I will miss my team and my co-workers when I leave. 
      Have you ever been in the same position and what did you learn from that?

      View full blog article
    • By Jimi Wikman
      As I am leaving the current project, due to the fact that I am leaving for another company, other people are taking over my duties and I get less and less involvement in the work that I used to hold together as the spider in the web.
      This is very difficult as I am used to be the one in the center of all things and now I am on the outside. The new team lead do things differently and the process of change always leave a residue of confusion and every fiber in my body just want to step in and "fix" things. 
      The thing is that there is nothing to "fix", it's just change and the fact that I no longer sit in the center of the project any more. The new team lead have things well under control and the project is doing just fine without me. 
      The realization that you really are not that important is both liberating an a bit sad. On one hand I am glad because it means that I have succeeded in making myself obsolete and the team no longer have need of my guidance. They work just fine without me following the processes and workflows we have built together.
      On the other hand I feel a bit like a parent no longer being needed by their children and they move from home. Just in reverse as I am the one leaving. It's a bit sad to realize that you will no longer be the one they come for when they need help or the one they turn to for advice and comfort.
       
      While this is a strange and sometime uncomfortable situation it is also a great opportunity to observe and learn from the new team lead and also to lift my gaze and look at things outside my part of the project.  It's quite interesting and it's a very good learning experience, especially when you can pick up on body language. I see so many things now that I have not yet had time to observe before and it give me a wealth of new insights.
      So I am in a position right now that feels a bit weird, mostly because I am not just leaving the project, but the company as well. It's also sad as I have to much time to think about how much I will miss my team and my co-workers when I leave. 
      Have you ever been in the same position and what did you learn from that?
×
×
  • Create New...