Category: Technology Consulting Page 1 of 2

5 reasons why I started a consulting business

By

On April 26, 2017

In MacIsaac Consulting, Technology Consulting

Consulting business

In 2015 I made a decision that would change my life. I decided to start my own consulting business. For years I worked in IT as an employee of various companies, including a large consulting firm. I always wanted to go out on my own, but I was afraid. I was afraid of losing “job security”.

The risk of taking the leap and then not being able to pay the bills was real, and it still is. After time, I concluded the risk was greater if I didn’t go out on my own. I figured the worst that could happen is it doesn’t work out and go back to being an employee.

Once my mind was set, I read all the books I could about starting a consulting business. When I drove to work, I listened to audio books by consulting gurus like Alan Weiss and Peter Block. I also studied content marketing. I learned about the power of social media and blogging.

Being a project manager, I treated starting my own consulting business as I would any project. I created a plan with tasks, costs, milestones and dependencies.

Little by little I began to complete the tasks in my plan. From naming my business and creating a website, to forming a corporation, I did it all. I did it in my spare time while still working as an employee.

I also reached out to everyone I knew who could give me advice. I have a great network of friends in business and their guidance was invaluable. Each time I met with someone for coffee, another piece of a puzzle came together. I always left the conversation with notes and more contacts to reach out to. I still meet people, some who I meet through blogging or LinkedIn, for coffee all the time.

It’s been a little over a year now that I’ve been working for my own consulting business and I’m so glad I did it.

Here are the 5 reasons why I started my own consulting business:

1 – There’s tremendous opportunity– Times have changed. Gone are the days when you would get a job right out of college and stay with the company until retirement. The advance of technology and globalization has changed the workforce landscape. Today it’s quite common for people to change companies around every 3 years. Opportunity surrounds us, and employees are smart enough to take advantage of it. People won’t stick around if they’re unfulfilled in their current job.

In consulting, especially IT consulting, there is no shortage of work. Technology is no longer this separate area of companies where geeks work in a silo. Business and technology skills are necessities of everyone today. There are IT projects galore!

If you have trouble finding direct client work, do not fear. There’s plenty of opportunity to work in a sub-contract Corp to Corp setup. If you land direct client business, you can bring on sub-contractors yourself. The opportunities are exciting!

2 – The pay is good– Consultants get paid well. They provide value by offering expertise that companies don’t have in house. If companies had the talent, they wouldn’t need a consultant. Companies will gladly pay top dollar if you can solve their problem.

If you work as an employee for a large consulting firm, you typically receive a small amount of your client billing rate. Large consulting companies rely on what’s called leverage to increase their bottom line.

Leverage enables consulting firms to make big margins off junior consultants. The money then flows up to the partners. Large consultancies actually depend on junior level consultants leaving the firm. This is necessary so a fresh crop of junior consultants can come in to continue the leverage.

To understand the business model of consulting companies, read “managing the professional service firm” by David Maister. If you’re committed to staying with a large firm, get ready for a game of thrones like culture to move up the ladder. You are competing with thousands of top notch consultants like yourself.

3 – The barrier to entry is low– Unlike most startups, you don’t need a lot of dough to start a consulting business. Aside from legal setup, getting a website and some other expenses, it’s easy to get up and running. Using the power of your network, blogging and social media, you can get the word out at no cost.

4 – I love being my own boss – Not reporting to a manager is a beautiful thing. So is forgetting about performance reviews, arbitrary goals, and administrative BS. I show up, do a good job, and get paid, that’s it! Also if I want to take some time off between contracts, I can do that. I’m my own boss.

5 – I don’t want regrets – This is the biggest reason I started a consulting business. I never want to look back one day and say, I wish I tried. I can accept trying and failing, but I can’t accept is not having enough courage to try.

Summary – If you are debating going out on your own, go for it. Put in the time to learn what it takes, and continue sharpening your skills. Once you make the leap, start blogging and using social media to get the word out there. It’s fun! Remember, we only live once. Don’t look back some day with regrets!

For me, I don’t know what the future has in store, but I know it’s going to be a wild ride. I have a feeling this journey has just begun.

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. Follow Mike on Twitter @MikeMacIsaac or subscribe to Mike’s blog.

 

Difficult project stakeholders? Here are 5 ways to deal with them

By

On April 17, 2017

In Project Management, Technology Consulting

5 ways to deal with difficult project stakeholders

Difficult Project Stakeholders

Project managers have an ethical responsibility to keep their project stakeholders informed. How much to keep stakeholder informed, and satisfied, depends on the level of power and interest of the stakeholder.

If you’ve ever managed projects, odds are you had to deal with a difficult stakeholder at some point. You know who I’m talking about, people who throw grenades at you and your project every chance they get. They might make last-minute scope change requests, send rude emails, or be confrontational in meetings. The list of possible difficult behaviors is huge.

They could naturally be a difficult person, of they may have it out for you and your project.

If you don’t know how to deal with a difficult project stakeholder, you could be in for a nightmare situation. Sometimes you need to use an unconventional approach.

Here are 5 ways to deal with difficult project stakeholders:

  1. The “olive branch” –  Go out of your way to engage with them early in the project. This is the diplomatic approach. Due your best to include them in the everything. Provide transparency. If they are showing signs of being difficult, acknowledge any concerns they have. Do your best to develop a positive working relationship. At this point, you are going on the offense to diffuse them. This is always my initial approach.
  2. The “keep em in the dark” – If you’ve done step 1 and it’s to no avail, it’s time to change the approach. If diplomacy isn’t working, it’s time to get tough and strategic. Nobody should let someone cause problems for their project. Managing projects are difficult enough, we don’t need people making it worse. The keep em in the dark approach means involving the difficult stakeholder as little as possible. Try to go around them and not let them do too much damage. John Kotter says the best way to deal with a change resister is to go around them. If the stakeholder has a high level of power, and interest in the project, unfortuntaely this approach is not an option.
  3. The “let’s do this!” – The “let’s do this!” means it’s time to drop the gloves and battle. Stick up for yourself and your project. Push back! Sometimes it can be effective when you tackle the problem head on. Don’t be afraid to disagree and meet with the difficult stakeholder one on one to give them a piece of your mind. Who knows, it could be they didn’t realize they were causing you problems.
  4. The “sound the alarm” – When all else fails, it’s time to escalate. Escalating to management about a difficult resource is a last resort. I try to avoid doing this at all cost. What your telling your manager is that a person is giving you a problem, and you can’t handle it. Now it’s your managers problem. Your manager can then decide if they want to take action and either speak to the stakeholder, or to their boss.
  5. The “okie-doke” – The okie-doke means keeping the difficult stakeholder involved to keep them happy, but don’t involve them in key decisions. Make them feel like they’re a part of the project, when in fact they’re not. You’re pulling the wool over their eyes. Manipulation is certainly not a preferred approach, but if all else fails….

Dealing with difficult project stakeholders is part of the job in project management. The steps I listed above can be helpful but only you can decide what approach to use. It depends on the level of power and interest of the stakeholder. If your sponsor is a difficult project stakeholder for example, you would never keep them in the dark.

How do you deal with difficult project stakeholders?

 

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. Follow Mike on Twitter @MikeMacIsaac or subscribe to Mike’s blog.

 

The rise of tech in Minnesota

By

On February 26, 2017

In Technology Consulting

Working as an IT consultant in the twin cities of Minnesota, I’ve seen firsthand the growth of tech. From large companies like Best Buy and UHG, to small startups, technical innovation is part of the culture. If you are local to the area or considering relocating, it’s a great time to work in tech in the twin cities!
 
Below is a great documentary about how Minnesota has become a tech hub:

 

For more content like this, subscribe to the MacIsaac Consulting Blog.

Mike’s Twitter @MikeMacIsaac

To contact Mike, click here.

 

 

 

Every IT project is a unique composition

By

On February 22, 2017

In Project Management, Technology Consulting

IT Project

A musical composition tells a story. Take for example, Mozart’s Requiem: Lacrimosa. As the music begins, the sounds of the soft strings and chorus provide a sense of mystery. The sounds fill you with wonder as you chart off into the unknown. The story has begun.

As the sounds and tempo begin to intensify, you go on an emotional ride consisting of high peaks and low valleys. The music eventually softens and the piece concludes. The story comes to an end.

In the same way, each IT project delivered is a unique composition that tells a story. Like Mozart’s Requiem: Lacrimosa, projects often begin with a sense of wonder. As you discover the project scope, it’s like the beginning of roller coaster ride. You slowly climb high into the sky. Filled with excitement and nervousness, you look around and realize you are in for a wild ride.

Suddenly, whoosh! You hit max speed into your first steep drop. The orchestra is playing at a pulsating high volume. The story has changed. No longer are you in the beginning of a discovery phase accompanied by soft strings and chorus, you are now surrounded by danger and chaos. Hold on because it’s going to be a wild ride.

Delivering the scope of your IT project will be as intense as Beethoven’s 5th symphony. Up until this point you only had a plan, but now you are in execution, where things get real.

Coming at you all at once are change requests, deadlines, defects and personality conflicts. These are just a few of the components that make up the challenges of the project story. On the flip side, team work, achievements, and feelings of accomplishment provide the high points.

The cast of the story usually includes a range of characters. Business executives, managers, team members and stakeholders all have a role to play. The main protagonists of the story are the project team members. For the story to come together like a great musical composition, everyone on the team needs to be in sync.

The leader of the team needs to be passionate, like an orchestra conductor. An orchestra conductor can hear the music so clearly that he or she can direct changes simply by waving their baton.

The project leader must do the same to keep the team on track. They need to direct the story and guide it to completion. If anyone is out of tune or out of sync, the project lead must correct it immediately.

In the end, all IT projects will complete. Whether they are successful or not, the music will fade away and the project team will move on. The story will come to an end.

The team then moves onto another project, where a new story will begin.

 

For more content like this, subscribe to the MacIsaac Consulting Blog.

Mike’s Twitter @MikeMacIsaac

To contact Mike, click here.

Is your project worth the investment?

By

On January 13, 2017

In Project Management, Technology Consulting

return on investment

Return on investment, or ROI, is a term you often here in the corporate world. ROI is not an actual financial metric, like ROA (Return on Assets). When you are talking about ROI, you want to know how much you will get back if you invest in something.

If an athlete invests a lot of time in the gym he will most likely perform better in his sport, which is the return. It’s the same with business. Companies invest in a new product, piece of equipment or project only if they expect a good ROI.

They spend cash they have now in hopes of realizing a return at some future date.

Sometimes managers have to fight with competing projects to receive funding for their project. If they can forecast a good ROI it will help them get the funding.

To determine ROI, you need to understand the time value of money. Over time the value of a dollar one year from now will be less than it is today. Three concepts used in analyzing investments are future value, present value, and required rate of return.

Future Value

Future value is what a given amount of cash will be worth in the future if it is loaned out or invested. Being able to predict the future value, especially for security investors, is crucial.  It can tell you whether your investment is a good one. If a stock is selling for $200.00 and is estimated to increase 20% over the next year, the future value of the stock in one year would be $240.00

Present Value

Present value is the opposite of future value. If the future value is worth $240.00 in 1 year with a 20% interest rate or increase, then the current value is $200.00

Required Rate of Return

If an investments value expects to increase 20% in three years, the increase percentage is rate of return. Before making an investment decision, investors will have determined a required rate of return. Say if a rate of return is only 3% over the next three years the decision might be to not make the investment.

Calculating ROI

The fancy term investors use when putting a value on a company is DCF (discounted cash flow analysis). For now, let’s look at the three popular methods for calculating ROI. These can be used to forecast a projects ROI. They are the Payback Method, Net Present Value method, and the Internal Rate of return method. The payback method is a simple calculation to determine how long it will take to get back the original investment. The Net Present Value method is more complicated but also more powerful because if factors in the time value of money. Net Present Value is the present value minus the initial cash outlay. The Internal Rate of Return (IRR) method is like except it calculates the actual return provided by projected cash flows.

For more content like this, subscribe to the MacIsaac Consulting Blog.

Follow Mike on Twitter @MikeMacIsaac

To contact us about our services, click here.

Don’t overlook the obvious

By

On December 21, 2016

In Leadership, Technology Consulting

Why is it that we love to over complicate things? Working as a consultant, when I see clients struggling to resolve an issue, the first thing I look to see is whether they understand the issue. Often time’s people get stuck trying to solve symptoms, rather than the root cause. They then become so fixated on a solution that they lose sight that the issue may be minor. All they needed to do was to look at the issue through a different frame of lens.

Case in point, the infamous defect tracking tool dilemma. Early in my consulting career, when I was with Accenture, I faced a big issue on one of my first projects. The client used two defect tracking systems instead of one.  The systems were out of sync which caused confusion and inaccurate reports. The client asked us to write a program that would keep the two defecting systems in sync.

When I first learned of the problem, I asked, couldn’t they just use one defect tracking tool? I was a newbie so I was a bit timid.  Immediately I got shot down by a senior consultant who said, we have to deliver what the client wants!

I was then assigned the dreaded task of creating a batch job, using excel macros, to synchronize the two defect tracking systems. After much hard work, I had working prototype in place. Meanwhile, my consulting firm flew in a high priced senior executive, who specialized in defect tracking tools, to help with the issue. His job was to look at the solution for the batch job and provide any input or recommendations.

What happened next is priceless. The senior executive arrives and the first thing he asks is, why can’t the client just use one defect tracking tool? Um, hello? Didn’t I suggest this when I first heard of the problem? Several meetings later they made the decision. The client would only use one defect tracking tool.

I guess it took a high priced senior consultant for people listen. It turned out the easiest solution was also the best solution

Next time you encounter some swirl around an issue, don’t overlook the obvious. Sometimes the best solutions are also the easiest.

For more content like this, subscribe to the MacIsaac Consulting Blog.

Follow Mike on Twitter @MikeMacIsaac

To contact us about our services, click here.

 

 

 

 

 

5 Reasons Why Teams Should be 100% Dedicated and Stable

By

On December 3, 2016

In Agile, Scrum, Technology Consulting

Stable Product Team

If your organization is not using stable product teams, they should be. A lot of organizations are still using an outdated balanced matrix structure. As an example, a company may have different departments or groups for each area of expertise. The project managers belong to one group, the developers belong to another, QA to another, and so on.

Before the fiscal year begins, the balanced matrix business conducts a prioritization process. They define what projects will take place for the year. Once projects are determined, a scramble takes place to form teams around projects. A battle will then ensue between management to staff the best people per project.

This model results in chaos and disorganization. It also results in creating teams that have little chemistry. Even worse, you end up with people assigned to many projects, resulting in switching costs. Some studies suggest that people can lose up to 40% of their productive time by shifting between tasks.

This must stop. Management shouldn’t move people around to different projects because a spreadsheet shows the people have ‘capacity’. It’s 2018, we now know that the highest performing teams are stable teams. The people on the stable teams should be 100% dedicated. What management should be concerned with is the throughput of the team, not resource usage. Efficiency does not always improve by increasing resource utilization. In fact, the opposite will happen if resources are over used.

The biggest reason for stable teams is related to team development. In 1965 Bruce Tuckman outlined four stages of group development, the ‘forming-storming-norming-performing’ model. Aside from having a catchy name, the model still holds true. It means that it takes time for teams to start performing well. This is a big part of the reason why it’s so valuable to have cross functional stable product teams.

Below are 5 huge reasons why your company should have cross functional stable product teams:

  1. With stable product teams, you no longer need to scramble to build teams around projects. All the chaos and competition around forming teams around projects goes away. No need to assign people to projects, instead, let product backlog items flow through stable teams.
  2. With stable product teams, work gets fed right into an already high performing team. This means you don’t have to deal with the forming-storming-norming phases of Tuckman’s model.
  3. Stable product teams improve quality. Quality improves because of the focus and attention the product receives. Team members also grow their domain knowledge and expertise. When team members are 100% dedicated, they won’t have to deal with switching costs.
  4. Work gets done faster and teams get better at predicting velocity. This reduces risk to the release schedules.
  5. Finally, stable product team members tend to enjoy their work. When team members sit together for a while, they get to know each other and they have fun. All the stable teams I’ve been a part of loved to joke around, bring in food, and come up with creative ways to have fun.

The stable product team model works well, perhaps best, using Agile Scrum. If your organization is not using Agile, stable product teams can still work well.

Whatever delivery process you use, let work flow through stable teams. Take advantage of teams that already have momentum, expertise and chemistry. Companies like Best Buy, Target and Pearson have long realized the benefits that stable teams have to offer.

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an Agile Delivery Consultant and IT Project/Program Manager. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

 

 

 

 

 

 

Servant leadership – 6 things I learned as an administrative assistant

By

On September 17, 2016

In Leadership, Technology Consulting

Servant Leadership

I often reflect upon past experiences that shaped my life for the better. I usually find that my most beneficial learning experiences were also challenging. It’s hard to see the benefits at the time we are going through a learning phase.

One such learning experience was my first real corporate job.  In 2000, back when we connected to the internet using dial-up modems, I took a position as an administrative assistant for UPS.  I was in my early 20s, studying computer programming and looking to start a career in IT.

The job was within the technical architecture department of UPS’s technology headquarters. Lucky for me, the office was just down the road from where I lived in Mahwah NJ. I knew the job wasn’t glamorous, but I thought maybe it could be a stepping stone.

When I started, I was partly embarrassed because most of the other admins were female. My friends would tease me and say I was a secretary. I made photo copies, scheduled meetings, ordered food, and did whatever the managers needed. At one point, they asked me to clean out the cubicle of a woman who left the company. I remember it shocked me to find pairs of shoes in her desk drawers. I doubt cleaning out cubicles was part of my job description, but I performed all my tasks to the best of my ability and with a smile.

The management team I supported at UPS were some of the best managers and leaders I’ve worked with to date. My role enabled me to interact with them often. They mentored me and it wasn’t long before they moved me into a software QA position. I was set on a course for a career in IT, just like I had hoped.

When I look back, the lessons learned during my time as an administrative assistant were invaluable.

Here are 6 things I learned about servant leadership by working as an administrative assistant:

  1. There is no substitute for being well prepared – I often had to prepare for department meetings and different events. Before the monthly department meeting, I would get into the room at least 30 minutes early to set up. I made sure all preparations worked without issue before anyone arrived to the meeting. This may seem trivial, but how often have you seen executives stumble through meetings because they weren’t prepared? Having trouble starting the conference bridge, not having a clear agenda, video problems…etc. All embarrassing flubs and potential career killers.  There is no substitute for being well prepared.
  2. When you’re called upon for help, provide it – Earlier I gave the example of cleaning out the cubicle of a woman who had left the company. When they asked me, I didn’t respond by saying that’s not my job. I put my ego aside and I agreed to the task with a smile. I not only cleaned out the cubicle, I had it sparkling. Sometimes we need to step up and do some dirty work. Leadership means doing whatever it takes to help the team. When I manage projects today and the team is in the trenches of project execution, I will do whatever I can to help. I’d be happy to bring team members coffee if they’d like, and I mean it.
  3. Always treat people with kindness and dignity –  I interacted with all different types of people. From executives to mail room assistants, I learned to treat everyone with kindness and dignity. At the end of the day, people are humans with emotions. You can’t treat them like COG’s on a spreadsheet. When you treat people well and show a genuine interest, they reciprocate.
  4. Don’t under-estimate the power of a smile – Maybe it was because I was working in an office instead of delivering pizza or working in a warehouse (my prior esteemed positions after high school), but I always walked around with a smile. My manager at the time, a wonderful woman, used to say…keep smiling Mike. When we smile, it sends a signal of warmth and trust to others. By making eye contact and smiling at others, it draws people to us. Think about those you worked for who walked around all day with a frown. Nobody want’s to work for someone like that. As leaders, giving a genuine smile is so important.
  5. Don’t be afraid of confronting team members – I often had to confront people when they were late with their status or administrative tasks. At first I was uncomfortable doing this because I thought I was bothering people. I later learned that most people appreciated it, because usually they needed a reminder. Top performing teams are not afraid to confront each other. Healthy confrontation is essential for trust and team building.
  6. Don’t forget to have fun – Work shouldn’t be a drag. As the person who was responsible for preparing slide decks for meetings, I was also in on all the gags. The team I was on at UPS always had fun. From pizza lunches, softball games, and bringing our guitars to department meetings, we had a culture of fun. We worked hard, but we played hard as well.

It’s funny how when we look back we realize what experiences were so meaningful. Working as an administrative assistant required some humility, but the experience was priceless.  Why? Because I learned about servant leadership and how to interact with people, and it’s all about people.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

 

 

Project Management – Why technical skill alone is not enough

By

On July 29, 2016

In Leadership, Project Management, Technology Consulting

Project Management – Why technical skill alone is not enough.

Project Management

Today’s changing business environment is becoming more and more complex. The global competitive economy is less predictable than ever. Organizations need project managers who have skills that support long-term strategy. For this reason, technical skills alone are not enough for project managers. PMI’s 2016 pulse of the profession report underscored this fact.

The report showed that business and leadership skills are in high demand. These skills, combined with technical skills, represent the PMI talent triangle (pic shown above). The ideal expertise areas are technical, leadership, and strategic and business management. “When organizations focus on all three skill sets, 40 percent more of their projects meet goals and original business intent.”

Companies should recognize the importance of business and leadership skills, and provide training. Many companies split roles to be either a “Business PM” or a “Technical PM”.  In my opinion this is a mistake. Instead of having two separate types of project managers, why not have just one that’s good in technology, business and leadership?

For new project managers, I suggest studying the three areas of the PMI talent triangle. Many good schools now offer flexible MBA programs with concentrations on leadership and strategy. I had the good fortune of going through the MBA program at Bethel University in St Paul Minnesota.  The program had a heavy concentration on leadership. As someone with a background in technology, the MBA helped me to become a better-rounded project manager.

For “technical” project managers like me, gaining business and leadership skills is crucial.  As the global economy continues to drive up complexity, the PMI talent triangle skills will be more in demand.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

 

Automated testing – The bottom line why it’s needed early and often

By

On July 15, 2016

In Quality Control, Software Testing, Technology Consulting

You need automated testing early and often because it reduces the cost of defects. “Defect Cost Increase (DCI) is one of the few empirical verified truths about software development: the sooner you find a defect, the cheaper it is to fix”(Beck, 2005). In a traditional waterfall project, all testing happens at the end of the project.

The waterfall based late testing approach results in high defect cost increase. As a former SQA analyst, I have experienced the pain that goes along with this process. Late nights working in WAR rooms, constant stress and continual red status reports. It’s the classic project death march experience.

In Agile and Lean software development, testing happens early and often. The team builds working software in short iterations. Testing is part of the software development process. In the below caption, Figure 14 shows the waterfall style of testing, compared to figure 15 which shows a more agile testing process.

FullSizeRender

One of the more popular and effective approaches is test driven development (TDD). Using TDD, the developer will first write an automated test. This test will ensure the basic functionality of the code works. After writing the test, he’ll first run it to see that it fails. Then, he’ll write his code, and run the test again to ensure the test passes.

By using TDD, the developer has already taken steps to ensure quality is built up front. The code then goes to QA, where integration, user experience, or performance testing happens. Just as the developer has created his automated test, so should the QA resource.

A high performing QA team will have an automated regression suite ready to run as soon as new code is ready. It is crucial that core functionality regression tests run first, before new feature testing. The idea is, make sure the new code hasn’t broken anything first, then begin the new feature testing. Most organizations have this backwards, doing all the regression testing at the end.

To put this all together you need the right tools, technology and resources. Whether it be JUnit, QTP, or Selenium, find the automation technology that’s right for your organization. Remember, the goal is to reduce defects and their cost.

Many organizations have avoided implementing test automation due to the expense. Ask any software quality team that uses automation and they’ll tell you the ROI is well worth it. If your organization builds software, you must use test automation. By not using it, you’re operating on an unsustainable model. It’s unsustainable because your regression test suite will continue to grow.  You cannot sustain a growing regression suite without automation.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

References: Beck, K (With Gamma, E.). (2005) Extreme Programming Explained, Upper Saddle River, NJ, Pearson Education, Inc

 

 

 

 

 

Page 1 of 2

Next

Powered by WordPress & Theme by Anders Norén