Great Products Consulting

Tag: project management

  • What you need to do to manage your development project

    What you need to do to manage your development project

    Regardless of what work you’re outsourcing to someone else to do, people often forget that you can’t just dump it on someone’s desk or inbox, and walk away. This is especially true when you’re getting someone to build you an online platform or mobile app. Since the building of your product is the most important part of getting it to market, it’s critical that you make the time to manage your development project.

    What’s does it mean to “manage” your project?

    At its most fundamental level, managing your project means that you have to keep an eye on what’s going on. It seems obvious, but most people don’t look beyond the basics of schedule and budget, which means they miss out on a whole lot of important stuff.

    Here are 5 key things that you should be managing:

    1. Cost
    2. Schedule
    3. Scope
    4. Risks
    5. Issues

    1. Cost

    Cost is how much you’re spending on your product development project. Yes, it’s probably the main thing that you want to track. Most people have fixed price contracts (i.e. a set price to do all of the work), which means that they only think about costs when their developers ask for more money. Regardless, of your contract, you should keep a close eye on your costs. The more money you spend upfront, the more you have to sell to pay off your investment.

    2. Schedule

    Time is another important part of your project. You want to have a clear view of when your developers will be giving you stuff (Hint: It should be in your contract.) If there are delays in completing development, then it will take you longer to get to launch, and you’re waiting longer to start making money.  Make sure you’re seeing progress in your project.

    3. Scope

    Scope is about building the things that were agreed to. You want to make sure that you’re getting what you asked for. Scope creep is one thing that’s really common in development projects.  It can cause your costs and timelines to blow out considerably. Scope also covers quality – developers may build what you want, but it might not work properly – and that’s not good either!

    4. Risks

    Risks are basically anything that might affect the outcome of your project. They come in all different flavours and can be in your control, and out of your control. Some examples of risk include regulatory risk, technology risk, legal risk, resourcing risk, financial risk – pretty much anything can be a risk. You want to have an idea of all of the key risks that might derail your project, and have a plan for mitigating them.

    5. Issues

    Issues are things that are raised, and need to be addressed during the course of your project. These generally are related to things that aren’t working as they should, or things that need to be resolved to complete a development project. For example, an issue might be that a button doesn’t work on a screen, or maybe your developers can’t get your website running on your host. You need to track and manage your issues to ensure that your project can finish successfully. You may not solve everything prior to your launch, but the important items will be fixed.

    In summary…

    Cost, schedule and scope are all tied together. If you increase the scope, it will cost you more, and take longer to build. Alternatively, if you’re behind schedule, you may need to get more people working on your project, which increases costs – or you can reduce how much you build. Finally, if you’re going too far over budget, you can reduce what gets built.

    Risks and issues run alongside of the other three. They can relate to any of the three issues, and to other things in and beyond your control.

    As the person that’s paying a lot of money for a developer, you have a very strong interest in seeing your product development project complete successfully. By having an awareness of these five factors for managing projects, you’ll be able to track and monitor how well things are going. More importantly, you have a head start when (not if) things go wrong.

    Want more tips on how to turn your idea into a great product?
    Read our Foundations for Non-Tech article.
  • 5 Foundations for non-tech people with platform or app ideas

    5 Foundations for non-tech people with platform or app ideas

    Software technology projects can be tough at the best of times, but what happens when you have an idea for an online platform or app,  and you’ve never done anything like it before?  In this article, I’ll explore some of the ways that non-technical people can get the foundations to set themselves up for success.

    As someone that’s been in the industry for a while, I can tell you that there’s no such thing as a “perfect” development project. However, if you come from a non-tech background, there will be things you just don’t know about, and frankly, it’ll make life more difficult for you. 

    Here are a few ways that you can get on the right foot:

    1. Understand the process
    2. Learn how to brief your developers
    3. Know what to build
    4. Keep on top of your development project
    5. Don’t forget the biz

    1. Understand the process

    Software and software-related product development processes are beasts in so many ways. The scope of knowledge and experience that people working in the industry have can be outstanding. Every day, I am awed by what people know and can do. So much goes on behind the scenes of tools, apps and applications that you use every day. This is not a journey where you can close your eyes and hope for the best. 

    While it’s not feasible or even necessary for you to become experts in this area – that can only happen over time – you should at least understand how the process works. You want to know what’s ahead of you and what’s expected of you. If you know how things are supposed to work, you can recognise when things are going wrong.

    2. Learn how to brief your developers

    A critical step in any product development process – not just a software one – is defining what you want (a.k.a writing requirements). When building online platforms and mobile apps, this is particularly difficult.  You have to describe your product, in detail, to someone who thinks in a completely different way than you do.

    Even the most basic digital products includes multiple features and functions. You’ll need to tell your developer what you expect each of those things to do. This means you have to become the expert on your product. There are many pitfalls and considerations when you write your requirements, and a non-tech person, you just won’t know what these are.

    Bottom line – if you can’t brief your developers properly, you won’t end up with the product that you want.

    3. Know what to build

    Along the lines of briefing your developer is actually understanding what you should be building. In software, you have an opportunity to test and learn.  

    As someone that’s not familiar with a very complex process, this presents a unique risk-mitigating option for you. Instead of pouring tons of time and money into an all-singing and all-dancing product, that may or may not make you enough money to pay off your investment – you can build it piece by piece. By knowing what to build, you have a greater chance of scaling and growing a product that people actually use. Ideally, you want to aim for the smallest possible product first.   

    4. Keep on top of your development project

    Once your development project is up and running, you can’t just sit back and wait for the finished product. Ultimately, as the owner of  your product, you want to make sure your developers are doing their job. You don’t want to wait until the end to find out what they’ve built is not what you expected.

    There are also lots of things along the way that can derail your project – both in terms of budget, schedule and what is delivered. Look for ways to be involved in your project. This might include regular status reports or meetings, design documents, sample screens, etc. If you can head potential minor issues before they become major problems, you’ll save yourself a lot of headaches.

    5. Don’t forget the biz

    Development costs are going to be one of the highest, if not, the highest cost that you’re going to have to get your product to market. The problem is, this often makes people forget about all of the other things that are needed to launch. 

    There are legal considerations around terms and conditions, and privacy. Make sure you protect yourself in terms of insurance and business structure. From an operations point of view, you also have to think about how to support your product – how will people contact you if they have a questions or a problem. An online platform or app is a 24 x 7 business so you need to think of the best way to handles inquiries. 

    The point is that your product is more than the platform or app you want to build. Products are often successful because of all of the other things that are needed to make it work.

    The bottom line

    Non-technical people build platforms and apps all of the time. 

    Sure, it would be less expensive if you were a developer, but then you probably wouldn’t have all of the other skills needed to launch and grow a product. 

    Gone are the days when you hire a developer, and trust that you’ll end up with what you want at the end. In these competitive times, knowledge is power. The more you know about software and product development, the more power you have to control your destiny. 

    Looking for a developer?
    Get my 10 essential tips for hiring the right developer for your project.
    Download it now for free!
  • Why you shouldn’t always rely on a recommendation

    Why you shouldn’t always rely on a recommendation

    Getting a recommendation from a friend or an acquaintance is a great way to find people or things – a plumber, a builder, a lawyer, a restaurant, a product, etc. Whatever you need, someone out there has a recommendation for you. In a previous article, I talked about using referrals to find a developer, and in today’s article, I’m going expand on why you shouldn’t always rely on those recommendations – especially when money is involved. When you’re building a platform or mobile app, you need people and tools to make it real, so you need some way to find these things. This article will talk mostly about people, as it’s a lot harder to ditch them when things go wrong – that’s what makes relying on those recommendations a bit trickier.

    Not all recommendations are created equal

    The first thing to remember is that not all recommendations are created equal. It depends on where the recommendation comes from. If you ask your partner or best friend, chances are, the recommendation is going to be fairly reliable. There’s a lot at stake for the person making the recommendation. They’re not going to recommend a dud – your personal relationship is at stake. If you rely on recommendations from online groups and forums where you don’t know the person, how good can that recommendation be?

    However, knowing someone personally doesn’t guarantee success. What you know of someone personally is very different from knowing him or her in a professional capacity. I’ve talked to so many people who hired developers based on personal relationships – and most didn’t work out.

    The next thing to note is that the recommendation may not be right for you. Imagine a friend tells you about this great restaurant – “you have to go there!” she says. “The food is great, the service is great, and they do really good cocktails”. Sounds good right? You go to the restaurant, and you don’t like the food. It’s expensive for what you get, and you have a really bad waiter.  So, it happens – not all recommendations turn out the way you expect.

    That’s the risk with recommendations. It’s subjective. What worked for someone else, may not work for you. There are many reasons for this – experience in different areas, size of the project, different services/tasks required, different expectations, conflicting personalities, etc. The list is endless. So, while a recommendation is a helpful, it may not be your holy grail.

    So, what can you do to make sure the recommendation is a good one?

    Heard of the saying “Buyer beware”? Well, the same applies when you get a recommendation.

    As with anything in life, researching the alternatives and doing some due diligence is key. Of course, the amount of effort you take to do this depends on how big a cost you’re looking at. If you buy something for $5 and it doesn’t work, then the risk of not doing any research is low. However, if you’re looking at spending at least $10K with a developer (often more), then it’s probably worth taking some time to see if it’s a good fit.

    Even though you’ve received a recommendation, you still need to check them out. Look at their website – do you like how it looks? See if they have examples or case studies of work that they’ve done – is it comparable to what you’re trying to do? Search for reviews. Look at their social media pages. Interview them. Get references and contact them. Basically, you need to apply the same due diligence as if you were hiring someone that didn’t come from a referral.

    Often friends or relatives will develop platforms and apps on top of their day jobs, so it’s a little bit trickier. They won’t have websites or past references to guide you. In this case, you might look at their professional background on LinkedIn. Does what they’re doing in their day job look anything like what you want them to do? How much do you trust them to do the right thing for your business?

    In many cases, it might be better to look at a few recommendations and make a decision between them. This has the added advantage of allowing you to see how different people and companies do things, so you can get a feel for what works best for you. You’ll also get to compare prices, and see what approach they’re recommending.

    Now what?

    A recommendation is a great place to start when looking for people and things. They can save you hours of hunting around, which cannot be underestimated. The lesson here is to approach with caution.

    Recommendations should only be about saving time on that first step of finding a shortlist of people to evaluate. They shouldn’t be a short cut for the whole hiring process. Given the importance of finding the right developer for your project, don’t rely blindly on recommendations. Consider the source and do your own checking.

    If you want a step-by-step checklist for hiring a developer and for turning your good idea into a great product, then my Idea to Launch Checklist is your plain-English guide to getting there. It’s available now for only $24. Click here to learn more.

  • How do you plan for your platform or app project?

    How do you plan for your platform or app project?

    Following on from last week’s “Idea to Launch checklist” announcement, I thought I’d share one of the areas covered in the checklist and talk about some of the tasks in it.  Today, I’m going to look at tasks in the “Plan your Project” list. Once you’ve decided that you want to turn your idea into a product and you’ve decided what you want that product to do, you have to think about how to get it built.  

    So, what does this involve? 

    The tasks in the “Planning your Project” checklist look at:

    1. Scope: deciding what you build
    2. Funding: getting the money to pay for your product
    3. People: determining who you need to get your product to launch
    4. Timelines: deciding when you want to launch and how to get there
    5. Tracking: setting processes for managing your project
    6. Risks: defining potential areas that will affect the success of your project

    Let’s take a look at these in a bit more detail:

    1. Scope:

    You know what you want your product to do, but how much do you want to build and launch at the beginning? This is your project scope. In a previous article, I talked about minimal viable products and starting with the smallest possible project. For this task, you want to think about what to include in your project now and what you want to do later. You’ll also want to think about how you’ll manage changes to the scope of your project – what happens if something new comes up while you’re building?

    2. Funding:

    This task is about figuring out where you’ll get the money to build your product. Will you use personal savings or maybe borrow from family and friends? Perhaps you can use a crowdfunding platform to get money from people that believe in your idea. Money can come from a lot of different places, so you’ll have to see what option is right for you. Be aware – unless the money is your own, it may come with conditions. You need to decide which ones are the least restrictive in both the short and long term.

    3. People:

    It’s very difficult to build any product without any help – especially a tech product. There are several tasks in this checklist related to people. First, think about creating a user group of potential customers that will be your sounding board as you develop your product.  This is critical to making sure that your product is built with your customer in mind. Also, think about the technical and non-technical people that will need to be involved in your project. What will each person need to do? Who will fill those roles? There are a set of tasks in the Idea to Launch checklist that deal specifically with hiring technical resources for your project.

    4. Timelines:

    At this stage, you might not know how long it will take to build you product. However, for business reasons, you might have a date in mind for launching your product. As you start to hire people for your project, you’ll be able to create a plan of key tasks and dates to get you to launch. You should also identify any key milestones that will be critical to meet in order to complete your project on time.

    5. Tracking:

    The key to staying on track in any project is to continually monitor your progress. The tasks in this area involve determining how you’ll do this. You might want to have a daily or weekly status meeting. There should also be a way to track your costs and where you are in your project. Finally, you want to manage any issues that might arise during the course of the project. There may be technical problems or other things that might increase your costs or delay your launch. You need a process for tracking and dealing with those issues.

    6. Risks:

    Risks are anything that might affect the completion of your project. They can be anything – the ability to get funding, not finding the right skills to do something specialised for your product, a piece of legislation that might affect what your product will do – the possibilities are endless, and will depend on your product. The point is that you need to be aware of the risks so that you can do something about them – before they cause you a problem. So, the tasks here include listing out your risks and deciding how you’re going to handle them.

    What happens next?

    The final task in the “Plan your Project” checklist is to hold a project kick-off meeting. Once you’ve got all of the pieces in place to start your project, then it’s good practice to get people together for a meeting. This is an opportunity for everyone to introduce themselves – but more importantly, it’s useful for setting expectations. You can provide some background to the project, and what you’re hoping this product will achieve. It also sets the stage for how you work together as a team.

    In the Idea to Launch checklist, you’ll also be hiring your developers as you plan your project. After that, the work of developing your product begins – both with technical tasks like designing and building, but also the business tasks of setting up your business.

    If you want to turn your good idea into a great product, then my Idea to Launch Checklist is your plain-English guide to getting there. It’s available now for only $24. Click here to learn more.

  • How do I prioritise what I want? (requirement prioritisation)

    How do I prioritise what I want? (requirement prioritisation)

    Prioritisation is probably a concept that you’re familiar with – you take a list of things and figure out which ones are more important than the other ones. Sounds simple enough?!

    When you’re building an online web platform or mobile app, prioritisation comes up all of the time! In this article, I’ll look at prioritisation as it relates to defining what you want your product to do. This notion of requirement prioritisation is a difficult one to grasp – because everything is important!  I’m going to take you through this process and share some tips for prioritising what you want.

    What are you prioritising?

    Requirements describe what you want your product to do. Requirements range from high-level statements (e.g. The user will be able to create an account) to detailed statements (e.g. The user will be able to create an account with their first name, an email address and a password). Every requirement needs a priority so you know how important it is.  

    Prioritisation methods

    There are really two main prioritisation methods:

    1. Low/Medium/High or Must Have/Should Have/Nice to Have; and
    2. Ranking

    Let’s look at each of these in a bit more detail:

    1. Low/Medium/High or Must Have/Should Have/Nice to Have

    This is a simple categorisation of your requirements based on the following criteria:

    1. High/Must Have: These are the things that have to be there in order to launch your product. They are critical to the success of your product. If these things don’t work, you have to delay your launch until things are fixed.
    2. Medium/Should Have: These are the things that “should” be there for the launch of your product, but don’t stop the launch from going ahead if they’re not built or not working properly.
    3. Low/Nice to Have: These are the extra things that you’d like your product to do, but they’re not all that important to your product right now.

    All of your requirements are given one of these priorities. Initially, your product will be focused on the “high priority” requirements, and if there’s time and money, the “medium priority” requirements can be included. Generally, your “low priority” requirements will be built after your initial launch.  

    2. Ranking

    Ranking is a straight-forward list that starts from 1 (the most important) and increases sequentially from there. It dictates the importance of one requirement relative to all other requirements. This is the method used in the Agile methodology to manage the list of things to be built. You start with 1, and keep going down the list until you reach your last requirement. You’ll have to decide which of the requirements on your list need to be included in your initial launch, and then you’ll continually develop your product after that.  As new requirements are discovered, these need to be slotted into the list based on their priority.

    How do you decide the priority?

    So, how do you decide if something is a “must have”? Which requirement is #1?

    There are several things to consider. Requirements are important if it’s:

    1. Critical to solving the main problem/need/goal you’re trying to address
    2. A legal, regulatory, or security requirement
    3. Needed for a satisfactory user experience
    4. Inclusion will help you to achieve your goals
    5. Driven by potential customer and user feedback

    The key is to be as objective as possible in setting your priorities. You may even have to test how important a requirement is by talking to potential customers and users. Prioritisation should be an informed business decision. Make sure you take the emotion out of it. You can’t make everything a “must have” – otherwise, you’ll never launch!

    Why is prioritisation important?

    You’ve prioritised all of your requirements, so how does this help you build your platform or app?

    Prioritisation comes into play when you’re deciding how much you want to build. Unless you’ve got all of the time and money in the world, you need to make decisions about what to include in your development project. If you’ve prioritised your requirements objectively, you start with your highest priority requirements first. Most people are constrained by their budgets, so prioritisation forces you to decide if you really need something or not.    

    Prioritisation also becomes a consistent and easy way to make decisions about your development project, and to communicate the importance of each requirement to your team. If a high-priority feature is taking longer than it should to build, or if there are issues with it during testing, then everyone knows what they should be working on.

    Prioritisation is ongoing

    After you’ve launched, you continue to add new features and functions to your product, and you’re going to have to decide what to build next. You should continue to prioritise these requirements, so that you can make objective decisions about the improvements you make to your platform or app. This will ensure that you’re spending your money on the right things – and that’s critical for your product’s success.

    Want to learn more about building and growing your platform or app? Join our email list to receive regular updates

    Just curious
    Evaluating my idea
    Ready to start building
    Building my product
    Launched my product

    * When you sign up for our list, we’ll send you emails that include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. We will not spam you. If you don’t wish to hear from us anymore, simply select the unsubscribe option at the bottom of any email that we send to you. To view our privacy policy, click here.

    << (previous) What's scope creep?
     
  • What’s scope creep?

    What’s scope creep?

    The term “scope creep” might conjure up images of spiders and other crawling insects, but it’s actually a real concept in software development. I introduced it in my article on “Tips for Building a Web Platform or Mobile App”, and now I’m going to expand on it to tell you why you need to be aware of it and how you can prevent it.

    Scope creep occurs when the size of a project increases after it has started due to the improper management of requirement changes.

    Huh?!

    Ok – say you have a project that starts with a list of 10 things to build. That’s the scope of your project. As you go through the project, you realise that there are another 5 things that you want to build. If you decide to include them in your project, your scope has grown by 50% to 15 things. That’s scope creep.    

    Why do you need to know about scope creep?

    Scope creep is an easy trap to fall into. When you’re building a product from scratch, there’s only so much that you know at the beginning. As you start the design and build process, you learn more about your product, and you think of more things you want your product to do. You want it to be perfect, so of course, you need to include it in the initial version of your product. The new requirement is added to your project – then another, and another – and all of a sudden, it takes months longer to finish the build of your product and costs you more.

    Your developers will love you! They get more money and you get the product that you want.

    So why is this bad?!

    Presumably, when you were planning to build your platform or app, you had a budget of some sort – the amount that you wanted to spend or could spend on development. Better still, you had an idea of the financials required to make your idea commercially viable (e.g. the numbers that you needed to hit to make money). If you fall into the scope creep trap, you might a) not have enough money to complete the building of your platform or app and b) your idea may no longer be commercially viable.

    This notion of scope creep also ties into my article the other week about a minimal viable product (MVP). People often have good intentions and start with building an MVP – and then they get excited – a competitor has this feature that you just have to include, and there’s this really cool feature that you think your users will love. Your initial release gets bigger and bigger, and is no longer an MVP. Also remember, that 80% of features in most applications don’t get used! There’s a good bet that many of your unplanned changes won’t materially affect your product in a positive way.

    What can you do to prevent scope creep?

    There are two main ways that you can prevent scope creep from happening.

    1. Define your product properly upfront
    2. Manage change to your product scope appropriately

    1. Define your product properly upfront

    Scope grows when you realise that there’s something else that needs to be included in your project. So, to prevent this from happening, you need to have a better idea of what you want to build upfront. This involves having a very clear, and often detailed, view of what you want your product to do. Take the time to think through every process and every function that defines your product.  You want to make sure you’ve captured different scenarios that might occur, and the features you want your product to have. This will allow you to have a well-defined scope for your project.

    The reality is that there’s going to be things that you miss – and that’s ok, because now you’re only going to miss a few things rather than lots of things. This is where the second method for dealing with scope creep comes in.

    2. Manage change to your project scope appropriately

    When you discover that there’s something else you need to add or change you to your product, then there’s a few things that you should do before you decide to actually build it:

    1. Prioritise the change: How important is it really? Do you need it in the first version or can it be something that’s added shortly after?  

    2. Get your developers to estimate the size and impact: Understand how much it will cost you to make the change, and how it will affect the overall project schedule.

     3. Evaluate the impact to your financials and business model: Use the numbers to see if you can afford to make the change. Does it affect the commercial viability of your product? Will delays disrupt your launch strategy? Do the benefits outweigh the costs?

    If you do all of this and decide the change is worth it, then go ahead and do it. This doesn’t have to be an extensive, drawn-out process. The point is that you’ve made an educated decision about changing the scope of your project.

    If you’re working under an agile methodology, recognise that your change may mean that something else doesn’t get done. This change may have a higher priority and cause another requirement to be pushed back. You’ve got to decide whether to extend your project to include the lower priority requirement or not.

    Not all change is bad…

    Despite all of this doom and gloom about scope creep, there are often very legitimate reasons for making changes to your project. The lesson here is that you don’t want to be caught unaware of what’s happening. It’s very easy to for a lot of small changes to accumulate and drive your costs up and delay your launch. So, before your start your project, be as sure of your can of what you want your product to do, and while you’re product is being developed, have a process in place so that you can make informed decisions about changes that you want to make to your product.

    Want to learn more about building and growing your platform or app? Join our email list to receive regular updates

    Just curious
    Evaluating my idea
    Ready to start building
    Building my product
    Launched my product

    * When you sign up for our list, we’ll send you emails that include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. We will not spam you. If you don’t wish to hear from us anymore, simply select the unsubscribe option at the bottom of any email that we send to you. To view our privacy policy, click here.

    << (previous) What kind of business do you want to be