My Articles

By 💫 Jimi Wikman · January 28, 20224 yr

Atlassian announced yesterday that they have acquired the small California based company Percept.ai, a company that focuses on AI technology to automize support flows, in quite impressive ways. This will strengthen the tool set of Jira Service Management with a new automation technology in the form of a no-code virtual agent that I think will add a lot to the Jira Service Management experience.
While Edwin Wong, the Head of Product Management at Atlassian, did not go into any details in the announcement, it is clear that this will be an important part of the future of Jira Service Management. I also think the acquisition of Percept.ai and their virtual agent technology will find its way into other areas of the Atlassian suite, and I would not be surprised to see an AI driven onboarding agent in the future!
I think this is a strong acquisition and an important one for the Jira Service Management product specifically and for Atlassian in general.

0

By 💫 Jimi Wikman · January 27, 20224 yr

Atlassian has just released their new product called Jira Product Discovery in Beta. It is a new project type in Jira Software, just like Jira Work Management, and sadly it is equally a bit lackluster when it comes to functionality. It is however a very nice addition and it has the potential to bridge the gap between business and IT, which is currently being done with creative setups in Jira Software.
So what is Jira Product Discovery?
In short, it is a tool for adding good ideas where you can define value and cost in order to make educated decisions on what to focus on first for your different products. Or just to start new products and value streams. Right out of the box in the Beta, we find many good features such as visual fields for effort and goal impact, the ability to score ideas and the most powerful aspect is the connection to create epics in other Jira projects to truly connect ideation with delivery.
Jira Product Discovery is a very nice new product that can compete with other tools like Aha!, but it is also a typical Atlassian product with limited functionality that may or may not expand down the road. This has been a problem for Atlassian in the last 5 years or so and it can affect the sales of this new product, unless it becomes part of the core like Jira Work Management is now.

Functionality looks great!
Even with the risk of having a less advanced feature set than some of the competitors, Jira Product Discovery have a good feature set already. Things like goals, what can target strategic values, or even smaller product goals is something I work with a lot. Things like effort ranking, key customers and connections to time periods and something they call buckets are all great features.
The ability to add automatic calculation of value is great, but I would like to see the ability to add negative values as well for things like risk and effort. Overall the score system is quite simple and it needs a more granular setup for it to be useful in large scale organizations.
Overall, I think this first iteration of Jira Product Discovery looks impressive and it will most likely fit many companies need as is.

It is a Beta
It is easy to point to things that are not awesome right now, but it is important to know that this is a Beta. As such it will be features that are either not yet there, not finished or that will change during the Beta. While I see several things that I think are essential for the future success of Jira Product Discovery as a product, I would not discourage any organization from trying this out even in its Beta format.
That is because this fit a very critical gap in the current product flora for Atlassian and I think this hit the spot pretty close to what a lot of people have been asking for, for a long time.
Don't take my word for it, though, head on over and try it out yourself.

Introduction Video

0

By 💫 Jimi Wikman · January 19, 20224 yr

Nothing makes starting a new year as exciting as getting new, fun toys to play around with, and for Confluence we have five of them to talk about today! Not only will you get some nice new ways to present your pages and data withing, but we also get some features that might very well change the way you work. So let us dive in.
#1 Page Status - a game changer?

I don't think I have seen anyone using Confluence without having a status in the page properties to indicate the current status of a document. Now we get a built-in function for this that looks very useful indeed. I can think of a million uses for this, but the question is how this works with things like page properties reports and different listing macros.

#2 Presenter Mode

The presenter mode looked a bit weird at first, but it has quite a few use cases where it works very well. One being training or education, and another is to present reports to stakeholders. I think it is a pretty nifty feature to be honest!

#3 Table visualization

The wet dream of so many managers is to visualize data with graphs. While this may be a very limited experience compared to other tools, it is very much a step in the right direction.

#4 Multiple Excerpt Macros

For me who advocate the usage of one source of truth, this is a very good addition. I often use excerpts for design documentation and for non-functional requirements, and I have sometimes wished I could have two or more sections to embed in different ways. With his update, I can now manage these things more freely. I like it. A lot.

#5 The new Confluence Home

This change looks really great and I can't wait to see it live. If you want to read more about this change, then check out this article: https://community.atlassian.com/t5/Confluence-Cloud-articles/Say-hello-to-the-new-Confluence-Home/ba-p/1892543

These are just a few of the new changes coming to Confluence in 2022 and I will do my best to cover all of them here on the blog and on the YouTube channel.
Which is your favorite of these and why?

0

By 💫 Jimi Wikman · January 1, 20224 yr

Jira is a great tool, but it is often abused by trying to make it do more than it does. One such abuse I see a lot is excessively long workflows, which is usually introduced by management. This is problematic because the longer the workflow, the more you will need to go up in scope for each issue. This is because there is no 1-1 relation between the different areas. This is the most common cause for having huge stories with tons of subtasks.
Before we go any further, let us first define what Jira is not.
Jira is not a project management tool, but it can be extended using Advanced Roadmaps to provide some support for this. Jira is not a resource management tool, but it can be extended using Advanced Roadmaps to provide some support for this. Jira is not a deployment tool, but it can have features that can provide information about deploys. Jira is not a code repository tool, but it has features that can provide information about code. Now, let us take a look at a common process flow for a company.

Based on this we can see that we can build something that support the Ideation where we make designs and prototypes. It would probably make more sense to just have a project with some tasks and then use Confluence, as much of what comes through ideation are never going to be realized. Definition is when we document more about the things that comes from ideation, and we would do that in Confluence most likely. Finance has nothing to do with Jira as we don't have connections to budgets, resources and so on. This is where Jira Align would be best suited.
Specification is the requirement process and that happen in Confluence and then we create stories in Jira for things to prioritize based on cost vs value creation before we hand them off to Realization. Verification is usually a part of the realization flow, but more often than not you would use an add-on for it. Acceptance is either a separate activity that also use the same verification add-on as test, or it is just informally part of the workflow.
Presentation is done completely separate and since we release groups of stories it rarely makes any sense to even have this in a workflow. This is what Releases/Versions are for in Jira. The whole maintenance bit where we deal with Incidents and problems is not connected to the realization flow, but it ties into the Specification. This, since the requirement, define what is an incident and what is not.
So based on this, we see that there is a clear distinction for where Jira is designed to work, and that is between realization and acceptance. This is the optimal fit and then you can extend this using Advanced Roadmaps so you can connect Realization to Finance to get that full span all the way up to strategic level.
What if I want to have a longer workflow?
Nothings says you can't have more. Jira is very flexible and you can do pretty much whatever you want. Before you do, however, make sure you understand who you extend the workflow for and what it means.
Extend with Deploy
This is probably the most common extension as a lot of people are used to having deploy, or rather release, as a part of their physical boards. Adding this to the workflow will add a blanket step. By this I meant that this step has no real purpose other than to inform people outside the deployment process where particular code has been placed. Using the version field will actually give this information in a much more organized way. You can also connect your CI/CD tool to automatically connect release information to your stories, which is probably the best solution if you work with continuous deploys.
If you add this in the workflow instead, then someone in the team will have to manually go over what stories are part of a package and then transition them one by one to next status at the time of the release. Considering that this step often happen well after the development, test and acceptance has been closed, it often happens that this is missed, leaving stories open long after they have been completed. Even if you remember it, you will still have multiple stories open in your boards, which will be a problem if you for example release infrequent or need to delay a release. If release is not done by the team, you will also have actions from another team in your board, which is a bit weird.
If you must have a way to visualize where different code is, then you should always use version. This will clearly show what code package a story belong to and you can filter it and also have a dedicated section for managing versions that you should tie to release notes and so on. If you absolutely can not communicate where a story has been released without having an issue on your board for it, then I suggest you connect all the issues to a release ticket. That way, you can manage the release just like any other task.
Adding this to your workflow means that you skip the version feature completely and since it is a blanket step it is prone to mistakes and lingering stories that very likely will mess up your statistics. If you have problem communicating releases to management and stakeholders, then I think you have bigger issues than your workflow...

Extend with requirements
Another common way to go is to use Jira as a requirement tool and by doing that extend the workflow to add more steps before realization. There are three major drawbacks to this, however: you need to have more fields added, requirements are not 1-1 with development, and Jira does not have version control or documentation capabilities.
As the requirement process have a different ritual and workflow than development, we need to add more fields. While this is usually not a big issue, it will clutter the backlog, as well as the content of each story. Each Jira project would need multiple boards to handle the two processes so it does not add confusion for the people working in each of the two processes. Overall, it will add more clutter and add complexity to the work in Jira.
In order to fix the second problem with requirements not being 1-1 with development, you would need to lift the abstraction level of the requirements. If you don't then you would make the user story 1-1 with development and that would mean that each development would have to be a subtask instead of a story. That makes it impossible for the developers to break out their own work further. This, however, often make each story an epic, which then means you no longer have any way to group several stories into a feature. Each story will also have quite a few development tasks compared to having multiple stories created for each user story.
The first two issues you can probably deal with, but the fact that Jira does not have documentation capabilities or version control should be a dealbreaker for any real requirement analyst. Not having a way to structure your requirements so you can find them and maintain them is a big issue, and it is why most people choose Confluence or an add-on to manage requirements. Not having documentation capabilities is also a big issue since you will be limited in what information you can add to your story, and you will most likely feel that this is claustrophobic and difficult to get a good overview of since there are so many other things displayed in the story.
Version control is a must for any requirement tool. This is for two reasons: you need to know what was agreed upon, and you must have a way to continue working. With version control, you can set points in time that you can restore to if needed. If you have worked with IT development for a while, then you probably have had a situation, or two, where unlocked requirements caused a lot of problems. This is especially true for design documents that are supporting requirements.
While it is certainly not impossible to add the requirements part to your workflow, you are again adding steps from a completely different process that have little to no relation to development stories in many cases. This is because requirements can, and will, become obsolete or too costly to be picked up for development during the requirement process. Just like with deploy, you will add complexity to the workflow and the boards, and the team will have information in the stories that are irrelevant for their area of responsibility.
The most common effect of adding requirement steps to a workflow is that there will be (at least) two boards. One for working with requirements and one for development. It is also very common that the stories will be larger to the point where work will mostly be done through sub-tasks to compensate for the lack of 1-1 relation.

Extend with business processes
This is not as common, but I see it from time to time. This is not a very good thing because the abstraction level goes way up and even the subtasks will be very large as the workflow starts on a project, or even program level. Even at the smallest amount of statuses for each step you will have a minimum of 14 statuses and I have seen workflows with up to 27 statuses. I do not think I need to tell you how painfull that was for everyone involved...
The problem with having business workflows included in the build workflows is that the business workflow and the build workflow are completely different. The business workflow is all about financing value creation and the build workflow is about realizing the need that has been approved in the business workflow. This means that there are three hard decision points that can stop the progress of the issues:
Ideation - Do we think the theory of value creation is motivated by the value the idea creates? This happens before we even consider looking into the issue further. Financing - What budget will the feature fit into? If it exist, do we want to prioritize it over other features and if it does not, how do we fund it? Specification - When we have broken down the feature so we know better how to realize it, is it still worth doing and if so should we prioritize it? While you certainly can extend the workflow and make a behemoth that will plague everyone in all aspects of your organization, you should consider the next aspects of mega workflows: Complexity and bloating. In order to support multiple processes in one workflow you need to extend the information in Jira as it is built for the built process. That means that you will need to add a lot of additional custom fields. This is bad because not only will it be much harder to work with a bloated issue where the majority of information will not be related to th work you do, it will also slow down the project a lot.
This problem will be even worse when you consider the amount of people that will need to have access to the project. Since you involve everyone up to a strategic level it means that everyone from business level down to realization will need to be included and working in the same projekt. I have seen Jira projects where thousands of people have worked in multiple teams, all with cusomizations to the workflow and content leading to hundreds of custom fields. Loading times could be as high as 3-4 seconds in a DC setup with load balancing and anytime you tried to look at the workflow the browser would crash.

Having the business processes in Jira is not a bad thing, but you should divide between business and build processes, preferably with Confluence as the middle layer to document requirements and tecnical solutions. Tools like Advanced Roadmaps or BigPicture can help extend the capabilities towards the business side as well.

Will it stand on its own?
One thing I always ask is if you can take the extended parts of your workflow and let it stand on its own, or is it actually a part of a singular process? I do this to see where people are in their mind so I understand how they think about the work. On one hand, I do understand the need to have an overview of the work from strategic level down to the smallest task in the operative level. I just don't think that Jira is the tool for that, because it is a task management system, not a program, or even project management tool. This is where Advanced Roadmaps and Jira Align comes in. These are the tools that should give you the overview (Advanced Roadmaps on Operations level and Jira Align on Strategic level).
When the users understand that having multiple steps in a process, where the outcome is not 1-1 with the next step, might not be the best solution, then you can show them what a board will look like with all those steps. The number of columns alone should be enough to see that a long workflow like that is not very useful. I have seen a workflow that required 27 columns, which of course is not something you can actually work with.
Use the correct tool instead
The solution in most cases is to not add more steps to a single workflow, but to extend the hierarchy and use something like Advanced Roadmaps, or split the work into two, or more workflows that can exist independently in different Jira Project.
In the series Setup Jira and Confluence - Introduction to setting up Jira & Confluence for success, that I will rewrite and make videos of in 2022, I will go over the tools and the setup in more detail.

I hope you found this usesful, and as always if you have any questions feel free to ask. No questions are stupid and if there is one lingering in your head, you can be sure others have the same questios, so you would make them, and me, a favor by asking it ❤️

2

By 💫 Jimi Wikman · September 16, 20214 yr

This week alone, I have seen two great companies stumble and suffer serious damage to their brand. Not only did they alienate customers and cause short term financial loss for themselves, they also cause long term damage to their brand and reputation. This is something that could have easily been avoided by simply following standard practices and putting effort into proper communication. In this article, I will give you my point of view of the events and some ideas on how this could have been avoided.
Atlassian - removing features and failing to communicate it
Atlassian have had problems with communications for a while now, and this in itself is a big problem. This week, however, I was preparing for introducing Advanced Roadmaps to a company I work for, and I was very surprised to notice that some features was missing. As it turns out, this was announced back in May on an obscured page in their documentation.
I assume that a notice was sent out around that time, but it seems it did not reach everyone (I never got the mails) and then apparently they did not think any more of this. A minor notice, barely noticeable in the release notes, can be found for the July 26th release. No marking to indicate that this will reduce functionality and rather than explaining what is being removed they refer to "live plans", which almost no one know what that is in reference to.

My question is: what information did new customers that signed up AFTER May 10th get regarding the fact that functionality they were buying would be removed later that year? When I upgraded to Premium, there was no warning and no mention of this, and I have not received a single email regarding this change.
To make matters worse, it seems that not even support knew this was happening so when I submitted a ticket to ask where my features had disappeared to, they referred to the differences between cloud and DataCenter. Obviously, they had no idea this feature was removed or that it had ever been a part of the cloud product.
So, how should this be handled to avoid upset customers that suddenly loose functionality from a premium product they pay a lot of money from? Well, the simple answer is of course to communicate. In this case, you have 2 communication paths to cover: existing customers and new customers.
Existing customers - Direct communication is a must. No one have time to read release notes or blog posts. People have companies to run, and removing functionality from a premium product is almost unheard of without a replacement product or alternative. On May 10th this should be a focused email to all premium customers where the changes in the product would be clearly communicated and detailed.

3 months before the removal, another letter should be sent to remind the customers about this change. Then again every month to ensure no one misses this information. Every release note from May 10th should have a notice at the top reminding of this change as well. This notice should be properly marked in red with a warning sign to illustrate its importance.
New Clients - Present changes up front. In the upgrade and order form, you should add a notice that the current implementation of Advanced Roadmaps will have changes happening soon that will remove features. You don't want to start a relation with a new customer with the feeling of lying and not being honest. While not a lot of clients was effected by this change, it has significant impact on TRUST. Not only do I not trust that Atlassian will keep me updated on changes to their products, especially when it comes to removing features, I also do not trust that they will be open with me when it comes to financial issues. This is a huge problem and I know that this is not just me feeling this way as I hear many other Atlassian consultants and customers starting to feel the same way.
Atlassian needs to step up their communication as they seem to be stuck in their corporate bubble lately and focusing more on making money than their customers. I think Pete Morris, the roadmaps/Advanced Roadmaps product owner, displayed this well in his response to me.

While Pete is a great guy and his response is kind and professional, it also shows a distinct lack of understanding of how to communicate with customers. In-product notifications are nice, if you assume that people actually read those, or even understand what they mean. Passive communication does not substitute direct communication, and more often than not the people who need the information are not the day-to-day users. It is the people in charge of tools and work processes and finance that need it, as well as the system administrators.
I will of course reach out to Pete and discuss this with him and others at Atlassian, not to point fingers, but to give my point of view to hopefully prevent similar situations in the future.

Invision Power Services - massive surprise price increase and reducing support without notice
IPS, the company behind the software I use here on the site, stepped into a hornets nest this week when they sprung a massive surprise change on their clients. Instead of a simple update to pricing and their support, they now have a PR nightmare on their hands. Their new website refresh that was supposed to be filled with praise over the new design is now a sad tale of angry and disappointed clients. When writing this the thread has 384 replies and it is bad...

So what really happened to warrant such a massive surge of frustration? Well, it was a combination of things, where I think the biggest issue was that people realized big changes to pricing and support by browsing the new website. There had been no information on this change beforehand, and the changes was quite substantial.
Price updates - This was a huge price change where people not only saw their price go up with anything between 30% all the way up to 300%. Most seemed to get a 50-60% increase in price, however, and while that surprise in itself was bad... Billing cycle changes - Payment periods was to pay the license fee every 6 months, but after the update this was changed to 12 months. Not only did people see a 50%-60% increase in license costs, it also doubled in size since it is now a yearly cost. For me, this meant that I went from $105 every 6 months to $310 every 12 months. That is a 50% increase for me. No more support, unless you pay for it - This was a very strange one as IPS now will shift everything towards community support unless you pay a whopping $1250/year. Yes, you read that right... $1250. Unless you pay over 100 dollar a month for ticket support, your support experience will be going through an open support forum. IPS claims that you can ask for private support or use the contact form if you do not want to post sensitive information in public, which seems very odd to me. For me, that just add a step for IPS support, the way I see it? It could have been different...
This could easily have been avoided, and it could even have been a positive spin on things if handled correctly. No one really mind the price change because we all knew that it had to come sooner or later. The change should have been done gradually, however, with the proper communication.
First announce the change 3 months in advance. IPS need to increase prices to up the development and support efforts. Everyone wants to see more features and bugs fixed faster. Everyone wants support to be better. Not a hard selling point to make. Offer anyone that want to commit to IPS to pay for a longer period of time now before the price change. - Show that you care about the current customers and also get a big chunk of short term cash to invest. Next renewal price remains the same for all existing customers - Again show that you care and appreciate the current customers by extending the existing price 6-9 months depending on when their next billing is due. #2 above should cover any current cashflow need, and you get a ton of goodwill. New customers pay the new price, of course. Offer multiple billing cycles. - Matt tried to motivate having just yearly billing with that customers can get confused or happen to pick the wrong cycle. I don't buy that as it is a UX issue and they own the product in charge of billing. I had a web hosting service for 15 years with multiple billing tiers and no one ever got confused by that. Having multiple options would help a lot for many that have problems funding $300 one time fee, but find it easier to fund maybe $30 monthly. Yes, you can do that anyway if you like with the ability to deposit money, but it is not something that people are used to. Define your support properly and offer ticket support. - While I get the idea to move questions to an open area to reduce the number of same questions being asked over and over, that is not the answer to the problem. I am all for the community driven help with IPS staff doing the heavy lifting, but you need to have an option for ticket support as well. I think it would have helped to put classification on the support tiers to make it easier to understand:
Tier 1 support - Paid Premium support with response time within 1 hour and a resolution time within 48 hours. You can even offer per ticket support where a customer can pay a sum for priority support either per incident or for say a month for example during a migration or critical sales period. Tier 2 Support - Ticket support in a private forum with only own tickets settings. This is used only for technical support issues, meaning that something is not working with your software. Tier 3 Support - Community driven support where you can ask any question and get help from the community as well as IPS staff. The key point here is to communicate, in advance, present the negative changes with a positive that motivates the negative. A price change should lead to improvements for the users, like better support and faster feature cycles or investments. This way you motivate the change and you give time to absorb it. This is important because the human mind is very sensitive to change and rapid change has a tendency to cause frustration or even anger.
IPS did the complete opposite by letting their customers discover the changes on their own and then selling the change with no upside for the customers at all. Instead the customers now pay more for less as prices went up and support was removed. That is a double negative, which is extremely hard to sell to your customers.
This was a part of the email that was sent out hours after the release of the new website and the new price model.

The wording and the way this is presented is directed inwards. It tries to motivate price changes with an historical reluctance to increase prices, which is pretty much what every landlord in the world do when they want to make more money and care nothing about their tenants. It has never been received well and it was not in this case either.
Claiming that the services and products hold great value is a moot point to make towards their customers. We know this, that is why we pay in the first place. What we want to know is why should I pay 50%-60% more tomorrow compared to today? What has changed and how do I get better value for paying more? Making claims that major features have been adding and referencing gamification (which is not a complete system btw), anonymous posting and Zapier integration does not really motivate why you want me to pay you more. I already have those features!
Switching to annual renewal billing because it is a simpler way and in line with industry standard show a distinct lack of connection with the customers and it is again directed inwards. It is not easier and more wanted for the customers, but many would have loved to have that as an option. I am of course talking about companies, but they are not the only customers IPS have.
The fact that this came out hours after the release of new prices and changes to support models enforces the feeling that this was an afterthought and that IPS care so little for their customers that they only informed them after they started screaming. I know that is not how IPS see their clients, but the perception is still there due to this mistake.
IPS failed in communication and people are leaving
Due to this very simple mistake to not communicate and not making sure the customers understand the reason behind the price change this has now caused many customers to cancel their subscriptions. This will have a ripple effect on the mod creators either leaving or increasing their prices substantially. Less mods means less customers and less customers means less community support, which leads to a feeling of abandonment and ultimately a reduction in sales.
Worse though is that IPS loose their customers TRUST. Again.
IPS is on a very dangerous path, and has been for a while, due to the fact that they seem to lack a communications officer that have experience with communication strategy and financial strategy. While Jordan is doing an amazing job trying to communicate with the customers on the forum and social media that is not enough to save them from blunders like these. Not even Matt trying to do damage control will do anything in this situation.
The damage is done.
The ony question is how will IPS handle this now that they have screwed up. They can either continue to ignore the vocal customers that do not approve of these changes, or they can roll back and make a new plan to roll out later this year.
If they ignore the customers I think they are going to have a really bad 2022, especially as people get back to life again and spend less time online again. Many struggle with finance now and it is not hard to motivate a move to less capable competitor with such a huge increase in pricing. Customers will drop like flies, not just because of the changes to price and support, but because they no longer trust IPS as a company.
If they roll back and make a proper plan in communication with their customers, then they have a chance to salvage some customers at least. Many will still leave due to the lack of TRUST, but the chance for redemption could salvage that to some degree. With the proper communication they can even turn this into a win, but that would require a communication plan that is very different than what we have seen so far from IPS.

Communication is not a nice-to-have!
If you run a company then you sould know that communication is not nice-to-have. It is an essential part of your business and if you fail in communication you not only can, but you will, damage your brand and business.
Anytime you deal with change for your customers, make sure your communication is aimed towards them. Make sure you present the benefit for them, not for you. Change is never accepted up front, so you must always sell it to prevent backlash. It is very difficult to fully recover from a communication mistake, but you can mitigate and in some cases even improve your relation with your customers.
So don't ignore the importance of good communication and if you are not a communications expert yourself, hire one. It will save you a ton of money from stupid mistakes like Atlassian and IPS have stepped into and it can increase your revenue a lot.
Good luck!

2

By 💫 Jimi Wikman · September 10, 20214 yr

Atlassian are raising the prices for their cloud services on October 12th, which is perfectly ok. What is a bit strange though is that they for some reason seem to purposely try to hide just how much they are raising the prices. It does not say in the email, and the link takes you to the FAQ rather than the price list. A price list that only have the new prices and not the old for comparison. It is a bit odd.
This seems to become a norm for Atlassian lately, to hide information and prevent comparison. I don't like it and I don't like the direction Atlassian is taking in terms of communication and information in the last few years. Atlassian used to be good and open about their prices, but lately it feels that they are doing everything they can to obfuscate and hide information purposely.
I am not sure if that is because they have a strategy to adopt dark patterns in their UX to prevent a clear view into the actual costs (like airlines do), or if it is just some bad practice on their part implemented by someone who don't understand the customers.
For example, why not include the new pricing in the email you send out to the customers? You know what products the customer own as it is part of your database, so it is not rocket science to add customized templates based on product ownership. If people could do that 15 years ago when sending out printed catalogs that had your car and your color on the front page, then I am sure that Atlassian can set up a simple database that can send targeted content to product segments.
Even if you can't because you have not done the work, or your master data is crap, you can still send the entire pricing table, or at least link to it! Instead, you send out a letter that say nothing with a link to a page that does not have the pricing information I am looking for.

Not even the FAQ landing page that Atlassian link to have a link in the text or any form of directional que to the single most important question clients will have when landing here: What are the new prices. Sure, there is a link component to the left, but nothing that indicate that these are related to the new pricing structure. It's just sloppy and poor UX in my opinion.

Once you click in to see the pricing tables, you would expect to see the new prices and the old one for comparison, right? Nope. Atlassian shows only the new prices. If you are anything like me, then you never really pay attention to the actual price per tier, you know your monthly cost, right? So it would be nice with a place to see your new cost based on the new prices... but nope. You just have to wait for the next bill to see what the new price might be.

As you can see, the start plans are going to be shafted once more. So if you have one, hold on to it because it looks like they will increase the price on that tier with 750%.

Now, it is not very difficult to present the information on the increase in a more useful way. Just add the information on both the old and new price, along with the changes in both value and percentage. This is what Jira Cloud Standard looks like, for example, if you spend 2 minutes on it:

I think this could be a problem because the person in charge of the INFORMATION is a designer used to work with PRESENTATION. Having tables that look good is one thing, answering the questions of the people looking for answers is another. If you present new prices that will affect people's decision to remain a client or not, then you better do better than this Atlassian.
This was not good, so step it up.
Ok?

0

By 💫 Jimi Wikman · July 30, 20214 yr

As the summer end and we are slowly crawling back to work from a long time working from home, people will start looking at new ways to work. Again. New buzzwords like mixed workplaces and work anywhere will mix with things like SAFe and Tribes, all driven from top management that need something new to call things. Here is the thing, though... You don't need it. Because the work has not changed and your need for control is due to a lack of trust. So let me explain why the processes are identical all over the world and how rituals may vary to improve them.
Process of making software and development.
I have to admit that I am constantly amazed over how little people understand the process of making software and develop things. Almost everywhere I go, people are so focused on the rituals that they seem completely unaware of the overlying process. Instead, they talk about Agile, Lean, SAFe and other rituals as if they were the process to make code. They are not. They are rituals on different levels. Their purpose is to add naming and rituals to the overlying process. The problem is that without understanding the process, they are just small pieces of a larger puzzle that more often than not, does not fit with other puzzle pieces.
So what is this overlying process, or master process if you will? It is the steps every development must go through, regardless of size. That is what a process is, after all. A series of activities that you repeat over and over. What are these steps then that you always take, and how can they work regardless of scale? Let us define them and see if you agree with me.

Ideation
Ideation usually involve visual design or some technical design, but it can also be feedback on the current solution. The purpose is to form some idea of something that can create value. I do not mean value for the end users, but for the company. This is an important distinction because some rituals only talk about end user value, which is actually irrelevant unless that lead to value creating for the company. This is also why some rituals are completely separated, or ignore the finance part of the process. The ideation part can be a very small tweak, a feature, a project or even a new product.
Definition
Once an idea has been formed, we define what the idea is. We do this with the purpose to make a cost and risk analysis to see if the idea can create enough value to be developed. This involves not just design and management, but input is also required from development and test to get complexity and high level estimates. Again, scale does not matter here, as we do the same for any level with more detailed work required the larger the scale becomes.
Finance
In this part, we match the value creation with cost of creation. Many rituals ignore this step and place it implicit on the role that own the financial responsibility. At large scale this has its own rituals like project planning and portfolio management, but even for small features or even tweaks we always make a cost benefit analysis. Or we should at least.
Specification
In the specification phase, we ensure that everyone involved understand what to build. We also set the rules for how to verify and accept. Again we make this at any scale where at the smallest level this might just be a verbal confirmation and an update to documentation, while in others it can be hundreds of hours of workshop and documentation. The aim is always the same: to ensure we understand each other and know how to verify that we have done things according to the need.
Realization
This is where we take the specification and realize it. Depending on our definition of done, we document what we build with the purpose to keep records of the system, so others can build upon the work.
Verification
In this phase, we verify that the specification has been fulfilled. That is all. If something fail to meet the specification, then it is returned to Realization in the form of a defect, or in large scale circumstanses, as contractual issues.
Acceptance
In the acceptance phase, we approve the development based on the specification, but we also try to determine if the specification was the right one. In the case that the specification did not yield the correct result, we can add new things into the ideation phase to correct. Making the wrong specification is not a fault of the realization, so it can not be defects.In large scale situations this is a contractual issue that is managed as a contactual conflict.
Presentation
The presentation phase is when the idea is finally presented to the end users. Usually this is done by releasing code to a production environment, but it can be done in various ways depending on the product.
Maintenance
This is the last step in the process where problems are managed within the build and presentation phases. This step can be either a time limited one, such as a post go-live support period, or it can be as a part of a maintenance project. Regardless, this phase is a bit different as it has a predefined finance attached to it and it only deals with problems such as incidents and repeating problems.

You always go through these phases
It does not matter at what level you are, you always go through these phases. This is why you will feel pain when your way of working skip one or more of these steps, and in my experience it almost always happen to be Finance, Specification and Acceptance at the lower levels. This is almost always based on the rituals, however, where misinterpretation of Agile along with poor definition of management responsibilities seem to be the biggest reason as I have seen it.
You can do some very small things to adjust this, however, ranging from a small checklist to a more detailed process mapping on need. A checklist can easily be done with just a few questions, where we just verify each phase to ensure we have not skipped any of them.
What is your idea? Is it technically feasible? How difficult would it be to realize it in terms of time and risk? Will the idea generate more value than it cost to realize it? Is this idea more important than other ideas in terms of priority? Do you understand what I want, and can you realize it within the time we have set? Is what we have realized in accordance with the specification? Are the end users happy with what we have presented? --- Maintenance below is usually a bit on the side --- Are there any problems that need to be taken care of?
Define the inputs and outputs
If you want to make this a more reliable process, then the next step is to have a set of workshops with each group to define requirements of input and output. Anyone who have spent time defining work processes have probably touched on this, but usually this is a top-down process where you focus on rituals, not the actual process.
I can not tell you how many times I have sat down with people who are very skilled with processes only to see completely blank faces when asking what the requirements for the input is from the developers. They never tend to get that far down, as they start at the top with finance and portfolio management down to maybe project management.
My suggestion is to start with the part where you will make the biggest impact, and that is at the bottom. If you shave off 10 hours a month for every project manager, that might seem to be a huge win. Until you compare it with shaving off 30 minutes of time for every developer and tester. In one company I worked for, I made an extremely low estimate that they lost more than one hundred million Swedish crowns every year due to lacking in the verification part alone. In the whole work process, they probably lost more than 10 times that...
Start with the Testers
NOTE: Depending on your organization and your rituals, you may have people with multiple roles. That is ok as long as they are clear on what role they are representing in each workshop. It may be required that you direct them from time to time if they drift to another role.
So I always start with the testers. This is because despite them being very important in the process, they rarely get to be involved where they should be. This is the same as for design, but their impact is less on the overall process since they exist in the ideation and specification parts. The format for this workshop is quite simple. Put a group of testers of different levels in a room, put up a square on a blackboard or big piece of paper with one side marked as "Input", the other side as "Output" and on the bottom you add "Dependencies".
Divide the group into 3-5 people each and ask them to write post-it's for each of the three sides. Input is what do you need to do your job, Output is what do you deliver to acceptance and dependencies are things that can affect your job. Give the group 20 minutes to write these things down, put it on the square. After 20 minutes, go over the notes together and define what the testers need to do their job, what their definition of done is and what dependencies they have.
The next step is to move over to the work process and discuss in what phase they see themselves participating and what their role is there. Rinse and repeat, but limit the time to 10 minutes for each phase, since most should already be up on the big square. Discuss again and create multiple squares, one for each phase.
NOTE: If you want, you can take this opportunity to define roles and responsibilities at the same time, or keep this for a separate session.
Then move on to the Developers
The next step is to talk to the developers with a similar exercise, but at the end bring up the testers requirements. The aim here is to match the developer's output with the input of the testers. This will show the gap between expectations of these groups, which you can then discuss. From this exercise, you might need to go back to the testers and make a separate gap analysis with them, and in some cases you might need to bring both groups together to get the gap closed properly.
Move on to the business side next
While it would make sense to take the Specification phase next we purposely skip that and lump the business aspekts into one big session. The aim for this session is to identify and separate the large scale aspects of the business side since we will handle them separately. So we try to focus the sesion on two parts: project management and line work. As both work with fixed budgets this allow us to focus on what input is needed to make good finanical decisions and how to prioritize.
In this session we focus on the Definition and Finance phase to get the input needed from Ideation and how that support the financial decisions. In this case we start with Finance, even if it comes last in the chain. That is because it is usually easier to define what input is needed in order to make financial decision. That will make the definition phase easier to define as well.
The trick for this workshop is to avoid getting into discussion of rituals. How decisions are made, in what cadence or what the decisions are called is irrelevant. The only thing that is important is what information is required to make decisions. If your organization have rituals that require you to submit a form-501 for change request that include a certain financial code, then that is a ritual, not a part of a process. Just note that down as that you need financial information about billing recipients and a dependecy to the portfolio process, or whatever is relevant to your organization.
Once you know what information you need to make informed decisions, then it is time to talk about the definition phase. How do we get the information we need from the Ideation phase may sound easy, but this is where things get a bit tricky. On one hand you want the perfect information for financial decisions, but on the other hand you don't want a 3 day documentation process to submit new ideas. So this is where the participants will get a bit frustrated, because we will kill their darlings.
That is right, we will take the requirements they made for the Financial phase and we will do a YAGNI excercise on it. Yagni stands for "You Ain't Going to Need It" and we will use that to mark all data we previously marked as input to the Financial phase. The aim is to remove as much as possible, or rather to simplify to the point where we can take good decisions without to much risk.
This can be a very tricky exercise if your organization have low trust, but it is crucial for you to get a proper process.
Bring Specification to the table
We now move on to the most crucial part of the process: The Specification Phase. This is the zone between the business parts and the realization parts. As such it is the most fragile part and it is prone to a lot of confusion within most organizations. This is why we take this after we do the Finance and Development phases.
Since we now have the requirements from the Development side and we have the expected outputs from the Finance and Definition side we have a starting point. In this workshop I tend to add multiple groups because we need Developent, Test as well as Design and Finance since they are the one that need to understand each other.
I tend to start with defining the purpose of the Specification phase first so everyone is on the same page.
The main purpse of Specification (Requirements) is to ensure everyone knows what the definition of done is. Specifications are legally binding. Payment is made based on them and defects are verified by them. Not all Specifications will be Realized (financial backloop) Specifications are historical records. With that in mind we can now start discussing the input and output of this phase. You will most likely see that there is a big gap here and that roles such as project managers, requirement analysts and product owners will express concern because the requirements on their job is much higher than they thought. You will most likely aslo see a big change in attitude from the development and test when the people on the business side start to realise just how much time these two groups spend chasing information that should have come from the Specification phase.
In this workshop it is important that we do not fall into a WE vs THEM situation. This can sometimes happen if the gap between the business side and the realization side is very big. If this happen, remind everyone that we are not there to complain on what is missing, but to collaborate to find ways to add things that we need. Together.
You probably also need to explain to the visual designers that they are part of two phases, the Ideation and the Specification. Many do not know the difference and they often think everything is exploration and ideation, which of course is not true. In the Specification phase we talk about design guides and approved design specifications, nothing else.
Mind the Gap(s) and sign the process.
With this we have pretty much defined all aspects of the process with input and outputs. You may have noticed that there are some phases that we have not covered yet, but don't worry. We actually have covered all the phases, but we just have not had workshops for all of them yet.
Ideation have an expected output from the Definition phase. The Acceptance actually get their expected input from Specification since that is what they will accept towards. This is also true for Maintenance that will focus on Incidents and repeated problems that both have to be defined in the Specification.
That leaves us with Presentation that is the phase where we deploy to production and release it to the end users. Since this usually does not entail a lot of requirements more than knowing what to release and when, there are situations where a more defined process is required. if this is the case for your organization, then follow the same workshop setup as the other ones and map input, output and dependencies.
Once you have all phases done you need to check for gaps that might still exist. So ask everyone that have participated in the workshops to verify their phases, but don't just ask for a thumbs up. Request that they fomally sign a decision document where they say they approve the definitions as they are stated. This is very hard in organizations that handle approvals through a consensus decision ritual rather than a formal decision ritual, but I suggest you insist. Not only will it make everyone take responsibility and thereby look a bit extra, it also visualize that someone actually have thought these things through!
That is something that is far more important than you think.
Brace yourself, change is coming!
Once a process is set everyone will examine it and they will apply their opinions to it. This is natural and it is a good thing, if you can manage it. Change for the sake of keeping things the way they are should be shut down as soon as it comes up. Change that improve the process should always be encouraged. Sometimes the way things are will fall into the category where it improves the process and if that happens improvements always win.
One thing you will notice is that everyone who bring forward thoughts on the process do so from a position of wanting to improve things. No one ever want to make things worse. Because they do not understand the process, or the difference between process and ritual however, they will make suggestions that are making things more bloated and complex. This is because they are blurring the lines between process and ritual and if you are not careful you will end up with a custom made ritual and that can be very expensive.
So what I do is I make a proper channel for input of great ideas. Each channel is tied to one of the process phases and each phase have a group that receive and review these changes. If a change is beneficial for everyone in that phase, then it is implemented into the process. If it is not, then it will not be included in the process. The key here is to make sure that the groups that are responsible for the input and output are the only groups that can approve or deny changes to that process phase.
Remember that the process itself rarely need any changes, but the rituals often require many and frequent updates.
How we use the Process with Rituals
Before I answer that we need to define what Rituals are. In my definition Rituals are a set of nomenclature (set of words), activities and roles. They can exist to cover one phase in the process, or multiple ones. They can also exist on different heirarchies, or scale, such as strategic and operative. They all have the same benefit and problem and that is that while they provide a unified way to discuss around things, they rarely play well with other rituals and they quickly grow to be bloated and encumbersome.
So if we take an operative ritual such as Agile for example, then we know that it is not designed to work on a strategic level. We would then use that preferrably on a line work setup where we have a defined budget, but not a defined scope. For this setup we would then take our process and use it to ensure we get all the input and output done correctly as part of the retrospective.
We can also easily see where the ritual have their weakpoints. Agile for example is high in Ideation and Definition is done collaborative as a parallell ritual. The weakest point of Agile is Specification because Agile is usually more verbal than documenting. So we define together how specification fit within the Agile ritual and add that to our definition of done.
By doing this we can easily discover shortcomings of our way of working with Agile, by examining output and input to ensure we don't miss anything. We can also make small adjustments to the ritual where there are gaps.
Is this overkill for small companies?
Not at all. Understanding what you do and how your work relates to the overall picture is very useful. I almost always hear people asking the same questions in every organization I work: what is expected of me? Even having this as a two hour exercise in a single team will make you work much better together. There is no size limit for when understanding expectations on you and the work you do stop being useful.
It seems very hard to do.
I assure you it is not.
Anyone can do this because even in worst case scenario you will still have had a healthy discussion on expectations in a pretty fun and interesting workshop. This workshop also doubles as a team excercise and an excellent opportunity to bring up problems and issues that may otherwise be difficult to raise.
The tricky part is to find the right level for the input and output. If you take the input for Realization for example one requirement is of course to understand what I am supposed to build. That is to generic so we define that in more detail so we say that for visual elements I need a design or wireframe as the minimum, or referral to components if you work with that. I also need acceptance criterias so I can verify my work. Perhaps I have dependencies to instructions on how the system works or code standards so I know how to write my code.
If you do not get it right the first time around, don't worry to much. You can always iterate and improve when needed.

Defining a process is a great starting point
Once you have a process that you can use as a base of what you do on a daily basis, then you have a very good start. It is very much the foundation upon which you can build your Taj Mahal of work processes that will make your employees create new wonders for the world to see with joy and serenity in their hearts.
So don't focus on interior decoration first, it will just be a bunch of fancy named furnitures thrown into the mud.
It is easier than you think!

0

By 💫 Jimi Wikman · July 3, 20214 yr

IT management software vendor Kaseya whose VSA software platform is used by other tech companies to monitor and manage customers’ IT networks, has been the victim of an audacious cyberattack. On July 2, the business issued a security advisory urging its customers to immediately shut down versions of VSA running on their own servers. It also suspended its own cloud-based VSA service.
Kaseya VSA is a remote management platform for MSPs that provides solutions such as automated patch management. According to Kaseya, the platform has been used by more than 36,000 MSP customers worldwide.
"Beginning around mid-day (EST/US) on Friday, July 2, 2021, Kaseya's Incident Response team learned of a potential security incident involving our VSA software," the company's CEO Fred Voccola said in a statement shared late Friday.
Kaseya's official recommendation is to:"IMMEDIATELY shutdown your VSA server until you receive further notice from us."
This attack already has compromised eight of Kaseya's MSP customers with 200 businesses linked to three of the victims reporting instances of file encryption. This Reddit post from huntresslabs show the progress of sorting out how to fix this ransomeware attack.
On Friday, Mark Loman, a malware analyst at security firm Sophos, tweeted the hackers demanded $5 million as ransom in exchange for the file decryptor. Image comes from thehackernews.com.

This seems to be quite nasty and here in Sweden it has affected one of our chain of groceries stores as they are unable to make payments due to this affecting their cashiers. In the US hundreds of companies have been affected and it is safe to assume that many companies in the EU and elsewhere might be affected as well.

0

By +Kryptera.se · July 3, 20214 yr

If you have the "Print Spooler" service enabled (which is the default), it means that anyone with access can execute code as SYSTEM against the Windows domain controller. At present, there is no patch from Microsoft. So take a break from your vacation and turn off the service immediately.
From Tenable's blog:
E5GOlYUXwAUyqzU.mp4
More information from Microsoft: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1675

0

By 💫 Jimi Wikman · June 27, 20214 yr

Atomic Design, or Functional Design as it is also referenced, is a bit of a weird beast. On one hand, it is a programmatic shorthand feature that allow you to use short code in development that then render CSS based on that, but it also a philosophy of sorts on how to organize CSS. A philosophy that very much resemble the inline-css era of old.
The problem statement
I think this statement says a lot on how ACSS and to some degree Atomic Design itself see the world of CSS. Anyone working with wild or free CSS development can certainly recognize some of these pain points. This is not uncommon in scenarios where many developers work in the same project or you have to work on top of a not so well-designed product.
The question is, though, how many still work in that way and why?
In a scenario where you have a defined design pattern, which should be the norm these days, this is rarely an issue. Regardless if you do atomic design or component design, your styles should be easy to maintain and define. Despite this I still see a lot of JS developers adopt inline styling and duplication of CSS in components. This is more common in libraries like React and Angular, I feel (personal experience, no real numbers to support that).
So it is not surprising to see a rise in areas like Atomic Design or ACSS since that help bridge the gap in skill levels some JS developers have and the inherent despise we have to spend more time than we have to on things we don't really enjoy doing. Not to mention, there are some benefits that should not be overlooked.
ACSS - Atomic Design as a preprocessor
ACSS is a preprocessor that will transform inline HTML variables and create CSS from it. It has a fairly simple syntax and it works by looping though the HTML and scrape up the variables and then make a CSS file from what it finds. In many ways, this is similar to inline CSS, but you would get a static CSS file instead of just printing it out in a style tag.
If we borrow an example from the excellent CSS-Tricks site that I highly recommend you check out, then here is a snippet of code where we declare some classes and input a variable to each.
<div class="Bgc(#0280ae) C(#fff) P(20px)">Lorem ipsum</div>The output from this would then generate the following CSS:
.Bgc$#0280ae$ { background-color: #0280ae; }.C$#fff$ { color: #fff; }.P$20px$ { padding: 20px; }This may seem quite useless compared to a well-defined CSS with variables declared that I could just input, but you could use both of course and use this to override in certain situations. Similar to how you would use inline styling.
The biggest benefit of this however is that the CSS generated would be as small as you could make it. This is because the CSS would be based only on what can be found in the HTML. This can be useful for development in for example Angular and React, where I assume this is mostly used.
In situations where you have classes reused over many components, like this website however, that would not really be as beneficial as having multiple CSS files is never a good thing and you would see duplication of classes. This is of course if you generate the CSS on a modular basis, but not if you render it globally on load somehow.
Overall, I do not see any need for me working with sites like Invision Community and I feel it would not really work well in an atomic design situation with defined styles in both the UI and the HTML/CSS that is reused across components.
I may be completely wrong about that, as I have not tried it and if so, sign off in the comments to tell me I am wrong 🙂

Atomic Design as a Philosophy
The idea of Atomic CSS is simple and, to be honest, not very new. The idea is to create single attribute classes and then stuff the HTML with them. Kind of like you would do using Inline styling, but with a global definition of the styles. It would look something like this.
/* naming utility classes */.relative {position: relative;}.mt10 {margin-top: 10px;}.pb10 {padding-bottom: 10px;}I say that this is nothing new because this has been around since before inline styling even existed. One reason it is not widely used is because it makes the HTML cluttered and hard to read. It is also a bit annoying to work with compared to having well-defined CSS classes as you will have a ton of attribute shortcuts basically rather than a library of styles.
If you are used to working with frameworks like bootstrap, then you are already familiar with the concept, since those frameworks also have libraries of smaller styles that you can mix and match. Atomic CSS is much smaller however and rather than having for example a flexbox class that have the standard values you use all over the site you have to build those up with a set of classes inline in the HTML.
Is it a terrible idea?
Atomic design as a concept can be traced back to October 2013 and an article written by Thierry Koblenz. It has since evolved and you will often see it in reference from the new breed of JS developers that work in frameworks like React and Angular. While it may be a bit unfair to say that these new JS developers do not have that same deep understanding of CSS as the "regular" front end developers, I do see this distinction growing.
For the JS developers however, this is pretty useful as they can focus on function rather than form. You have probably seen the mess that sometimes happen when JS developers mix inline styling, component specific styling and global styling. It is as bad as having multiple novis CSS developers trying to use EM when they do not control the output containers...
I hear some arguments that this makes it easier to avoid specificity issues, but I do not agree with that. If you control your code, then you are a pretty bad developer if you can't handle your classes properly. It all comes down to planning and setting structures after all, unless you are just playing around like I do on this site.
I digress though and to answer the question if this is a terrible idea I think there are use cases for when this can be useful. Since that article in 2013 however, I think those use cases are less now, especially with the introduction of CSS variables. I do however think there is a very good case for using this same idea for defining variables and to keep your classes small as a philosophy.
I do think there are certain scenarios where it is a good idea to use the concept of Atomic design, and that is for overrides. Things like fonts, colors and spacing can be useful to sometimes just make a small adjustment rather than building new components.
Also, if you generate your content at runtime on the server, there are benefits to this since you can combine it with CSS-in-JS to dynamically generate very small CSS files. I guess this is why React and Angular developers are liking this way to organize your CSS classes. You can still do this working with regular CSS, but the files will be bigger since you are bound to have duplicate attributes in your classes.
So it is not a terrible idea, but it comes with some issues.
Allow me to explain...
My Thoughts
While there are benefits in some cases, there are some negatives as well. The biggest issue for me is that while we reduce the CSS, we instead increase the size of the HTML. The HTML also becomes much more cluttered and harder to read because unlike CSS where we can group classes, or even split them on multiple files, HTML will just be one big garbled mess.
Consistency is also an issue because the idea of recreate clusters of classes to achieve the components is done manually every time, then you will see consistency go out the window. We see this all the time in wild or free CSS, where pretty much every component have its own class styles uniquely. This is especially problematic if you have JS developers that are not very good at using CSS and you try to set up a design library.
At the end of the day however, front-end developers are flexible and resourceful people. All of these potential pitfalls can be managed and if Atomic CSS works for you and those that you collaborate with, then go for it. Just don't make the decision just in the development team as you need to work well with both Design and Test so they should have a say as well. Also, your way of working must work across teams, so don't start using Atomic CSS if you at any time will have other teams working in the code as well.
You know all that of course, but it is something that you can never repeat too many times.

Do you use Atomic Design today?
If you do, what benefits and pitfalls have you uncovered?

0

By 💫 Jimi Wikman · June 8, 20214 yr

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 within 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 🙂

0

Atlassian acquire Percept.ai - strengthening their ITSM products even further

Jira Product Discovery - The missing link between business and IT?

5 new features in Confluence to kick off the new year with

Long Workflows in Jira - Multiple processes in one workflow is problematic

The Importance of Communication - when TRUST dies horribly and organizations fail

Price increase - but why the obfuscation Atlassian?

Rituals and Processes - How to make them work, for real

Criticial Ransomware Incident - Massive cyberattact through tech provider Kaseya

Serious vulnerability in Windows Print Spooler "Print Nightmare"

Atomic CSS - what is it and is it useful?

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

Categories

My Articles Filters

Latest Community articles

Affordable Linux Dedicated Servers for Businesses | High Performance

Dedicated & Cloud Server Hosting Experts | 24x7 Support

Benefits of Using ReactJS for Your Web Development Project

Kotlin Vs. Java: Which is Best for Developing Android Apps?

CodeLobster IDE - free PHP, HTML, CSS, JavaScript / TypeScript editor

Who's Online 0 Members, 0 Anonymous, 17 Guests (See full list)

Account

Navigation

Search

Configure browser push notifications

Chrome (Android)

Chrome (Desktop)

Safari (iOS 16.4+)

Safari (macOS)

Edge (Android)

Edge (Desktop)

Firefox (Android)

Firefox (Desktop)