blogarticle
7 pitfalls to avoid for non technical project managers
I read a great article this morning on linkedin - Not a coder? No problem: Concrete advice for non-technical founders, Mark McDonald - that got me thinking. His article made some excellent points, many of which I would agree with whole hearted, although it can be dependant on the working environment and budget available.
What really caught me my eye was his 7 pitfalls to avoid if you want to build a great app that are as follows:
Pitfall #1: Calling up a dev firm or contractor, describing your idea, and asking for the cost
I would support Mark's assertion that "if someone can give you an exact price tag or time-line after a five-minute phone call or a single email, they?re setting you up to fail." We are often asked if we can give a rough budget on a project after very limited discussions, during the initial sales call and simple say, we don't have enough information at this stage to furnish you with an accurate estimate that you could use for your business.
We insist on clients following our methodology that ensure we can arrive as a one or more well defined outcomes, before even attempting to propose a solution and arrive at budget.
Pitfall #2: Going too agile or too heavy
Whilst agile is all the rage, going for this approach can result in feature creep, if not managed properly; feature creep is a sure way to blow you budget and delay implementation. I am not saying agile is bad, per se, but it does have it's disadvantages and if you don't understand them, then don't fall for technical jargon like agile, scum, waterfall ...
Worth noting that Mark makes some excellent comments about other things to consider, like security, performance and maintainability! Agile code can get messy of not managed properly, with constant changes and updates.
Pitfall #3: Fully delegating your project requirements
Requirements capturing is essentially to the knowledge transfer between the development team and your business. It's essential to take an active role in this, as you need to allow the development team / analyst to ask questions to establish the issues and outcomes (see methodology).
We love this stage of a project, as it is when we can truly challenge your businesses beliefs / concepts. It's like behaving like a petulant child and asking "why" (perhaps that's why we love it so much).
Pitfall #4: Failure to prototype
Within the SME environment, most businesses can't afford prototyping, but ask for wire frames instead and make sure you really understand the specification. You should be able to use it to ru through different situations to ensure the proposed appraoch can manage all the exceptions. Having said that, bare in mind, if a system is able to cope with every exception, it will come with a price tag. Work out which exceptions can be managed outside a solution, if the cost is too high.
If you need prototypes for more complex solutions, expect to pay for them.
Essentially, the later you realise an assumption is incorrect the more it will cost. It's therefore better to challenge everything as early as possible, hopefully whilst still on the drawing board.
Pitfall #5: One-dimensional product testing
Ensure User Acceptance Testing (UAT) is planned. If you don't know how to do this ask your software house for testing procedures and / or hire a 3rd party to help you. It is one of your main responsibilities and you need to make sure you understand what these are. Don't under estimate how much time this takes.
As Mark says, "If the code is sound, the app should work", but don't assume anything, developers are not mind readers and certainly don't have crystal balls.
Pitfall #6: Waiting until the end of the project to see working software
These days, we work primarily on web based solutions, so rolling out an update is relatively easy (although not always the case). We would recommend you agree milestones with your developers and ask for a beta version of your software when each milestone is reached.
Whilst it is tempting to them flood the development teams in box with feedback, trust me, developers hate it. Try to organise feedback and liaise with the development team's project manager on who, what, when should be fed back to the team.
It's also imperative that your team fully engage in projects from start to finish. We know you are busy, we all are, but don't slope shoulders and then blame the developer afterwards, because you didn't answer questions promptly, when asked. It is one of the most common issues for a break down in relationships and projects ...
As Mark says "seeing early versions enables you to course correct if a feature has been implemented incorrectly or user feedback suggests a different approach."
Pitfall #7: Not reviewing your code during the build
No matter how good the development team is they will make mistakes, typo's etc because the are so close to the project. That's why it is important that someone from outside can see the wood through the trees.
Mark goes on to highlight other important considerations
1. Implement a daily or weekly stand-up meeting to clear impediments - we tend to use weekly progress reports, but be prepared to answer questions quickly to avoid delays in development.
2. Stay calm and collected
Basically, do everything you can to keep calm - even if the project gets stressful. We all want to work with people we like and who treat us with respect, so dont take your concerns out on the development team. If something is seriously going off the rails, talk to the project manager. Find a solution together. And theres always a solution if you get creative and strategic.
I have quoted Mark, almost verbatim, as he has hit the nail on the head!
3. Manage your own team dynamics
Again, Mark nails this one:
"Want to drive your development team crazy Switch up the decision-maker from one day to the next. It's amazing how quickly this misstep can cause project meltdown. If you're not a solopreneur, designate one person who will consistently communicate with the development team. Decide who makes the final call on technical issues. Keep your own internal flow clear and you'll save major time and money."
Date: 02/08/2017
7 pitfalls to avoid for non technical project managers
I read a great article this morning on linkedin - Not a coder? No problem: Concrete advice for non-technical founders, Mark McDonald - that got me thinking. His article made some excellent points, many of which I would agree with whole hearted, although it can be dependant on the working environment and budget available.
What really caught me my eye was his 7 pitfalls to avoid if you want to build a great app that are as follows:
Pitfall #1: Calling up a dev firm or contractor, describing your idea, and asking for the cost
I would support Mark's assertion that "if someone can give you an exact price tag or time-line after a five-minute phone call or a single email, they?re setting you up to fail." We are often asked if we can give a rough budget on a project after very limited discussions, during the initial sales call and simple say, we don't have enough information at this stage to furnish you with an accurate estimate that you could use for your business.
We insist on clients following our methodology that ensure we can arrive as a one or more well defined outcomes, before even attempting to propose a solution and arrive at budget.
Pitfall #2: Going too agile or too heavy
Whilst agile is all the rage, going for this approach can result in feature creep, if not managed properly; feature creep is a sure way to blow you budget and delay implementation. I am not saying agile is bad, per se, but it does have it's disadvantages and if you don't understand them, then don't fall for technical jargon like agile, scum, waterfall ...
Worth noting that Mark makes some excellent comments about other things to consider, like security, performance and maintainability! Agile code can get messy of not managed properly, with constant changes and updates.
Pitfall #3: Fully delegating your project requirements
Requirements capturing is essentially to the knowledge transfer between the development team and your business. It's essential to take an active role in this, as you need to allow the development team / analyst to ask questions to establish the issues and outcomes (see methodology).
We love this stage of a project, as it is when we can truly challenge your businesses beliefs / concepts. It's like behaving like a petulant child and asking "why" (perhaps that's why we love it so much).
Pitfall #4: Failure to prototype
Within the SME environment, most businesses can't afford prototyping, but ask for wire frames instead and make sure you really understand the specification. You should be able to use it to ru through different situations to ensure the proposed appraoch can manage all the exceptions. Having said that, bare in mind, if a system is able to cope with every exception, it will come with a price tag. Work out which exceptions can be managed outside a solution, if the cost is too high.
If you need prototypes for more complex solutions, expect to pay for them.
Essentially, the later you realise an assumption is incorrect the more it will cost. It's therefore better to challenge everything as early as possible, hopefully whilst still on the drawing board.
Pitfall #5: One-dimensional product testing
Ensure User Acceptance Testing (UAT) is planned. If you don't know how to do this ask your software house for testing procedures and / or hire a 3rd party to help you. It is one of your main responsibilities and you need to make sure you understand what these are. Don't under estimate how much time this takes.
As Mark says, "If the code is sound, the app should work", but don't assume anything, developers are not mind readers and certainly don't have crystal balls.
Pitfall #6: Waiting until the end of the project to see working software
These days, we work primarily on web based solutions, so rolling out an update is relatively easy (although not always the case). We would recommend you agree milestones with your developers and ask for a beta version of your software when each milestone is reached.
Whilst it is tempting to them flood the development teams in box with feedback, trust me, developers hate it. Try to organise feedback and liaise with the development team's project manager on who, what, when should be fed back to the team.
It's also imperative that your team fully engage in projects from start to finish. We know you are busy, we all are, but don't slope shoulders and then blame the developer afterwards, because you didn't answer questions promptly, when asked. It is one of the most common issues for a break down in relationships and projects ...
As Mark says "seeing early versions enables you to course correct if a feature has been implemented incorrectly or user feedback suggests a different approach."
Pitfall #7: Not reviewing your code during the build
No matter how good the development team is they will make mistakes, typo's etc because the are so close to the project. That's why it is important that someone from outside can see the wood through the trees.
Mark goes on to highlight other important considerations
1. Implement a daily or weekly stand-up meeting to clear impediments - we tend to use weekly progress reports, but be prepared to answer questions quickly to avoid delays in development.
2. Stay calm and collected
Basically, do everything you can to keep calm - even if the project gets stressful. We all want to work with people we like and who treat us with respect, so dont take your concerns out on the development team. If something is seriously going off the rails, talk to the project manager. Find a solution together. And theres always a solution if you get creative and strategic.
I have quoted Mark, almost verbatim, as he has hit the nail on the head!
3. Manage your own team dynamics
Again, Mark nails this one:
"Want to drive your development team crazy Switch up the decision-maker from one day to the next. It's amazing how quickly this misstep can cause project meltdown. If you're not a solopreneur, designate one person who will consistently communicate with the development team. Decide who makes the final call on technical issues. Keep your own internal flow clear and you'll save major time and money."
Date: 02/08/2017
7 pitfalls to avoid for non technical project managers
I read a great article this morning on linkedin - Not a coder? No problem: Concrete advice for non-technical founders, Mark McDonald - that got me thinking. His article made some excellent points, many of which I would agree with whole hearted, although it can be dependant on the working environment and budget available.
What really caught me my eye was his 7 pitfalls to avoid if you want to build a great app that are as follows:
Pitfall #1: Calling up a dev firm or contractor, describing your idea, and asking for the cost
I would support Mark's assertion that "if someone can give you an exact price tag or time-line after a five-minute phone call or a single email, they?re setting you up to fail." We are often asked if we can give a rough budget on a project after very limited discussions, during the initial sales call and simple say, we don't have enough information at this stage to furnish you with an accurate estimate that you could use for your business.
We insist on clients following our methodology that ensure we can arrive as a one or more well defined outcomes, before even attempting to propose a solution and arrive at budget.
Pitfall #2: Going too agile or too heavy
Whilst agile is all the rage, going for this approach can result in feature creep, if not managed properly; feature creep is a sure way to blow you budget and delay implementation. I am not saying agile is bad, per se, but it does have it's disadvantages and if you don't understand them, then don't fall for technical jargon like agile, scum, waterfall ...
Worth noting that Mark makes some excellent comments about other things to consider, like security, performance and maintainability! Agile code can get messy of not managed properly, with constant changes and updates.
Pitfall #3: Fully delegating your project requirements
Requirements capturing is essentially to the knowledge transfer between the development team and your business. It's essential to take an active role in this, as you need to allow the development team / analyst to ask questions to establish the issues and outcomes (see methodology).
We love this stage of a project, as it is when we can truly challenge your businesses beliefs / concepts. It's like behaving like a petulant child and asking "why" (perhaps that's why we love it so much).
Pitfall #4: Failure to prototype
Within the SME environment, most businesses can't afford prototyping, but ask for wire frames instead and make sure you really understand the specification. You should be able to use it to ru through different situations to ensure the proposed appraoch can manage all the exceptions. Having said that, bare in mind, if a system is able to cope with every exception, it will come with a price tag. Work out which exceptions can be managed outside a solution, if the cost is too high.
If you need prototypes for more complex solutions, expect to pay for them.
Essentially, the later you realise an assumption is incorrect the more it will cost. It's therefore better to challenge everything as early as possible, hopefully whilst still on the drawing board.
Pitfall #5: One-dimensional product testing
Ensure User Acceptance Testing (UAT) is planned. If you don't know how to do this ask your software house for testing procedures and / or hire a 3rd party to help you. It is one of your main responsibilities and you need to make sure you understand what these are. Don't under estimate how much time this takes.
As Mark says, "If the code is sound, the app should work", but don't assume anything, developers are not mind readers and certainly don't have crystal balls.
Pitfall #6: Waiting until the end of the project to see working software
These days, we work primarily on web based solutions, so rolling out an update is relatively easy (although not always the case). We would recommend you agree milestones with your developers and ask for a beta version of your software when each milestone is reached.
Whilst it is tempting to them flood the development teams in box with feedback, trust me, developers hate it. Try to organise feedback and liaise with the development team's project manager on who, what, when should be fed back to the team.
It's also imperative that your team fully engage in projects from start to finish. We know you are busy, we all are, but don't slope shoulders and then blame the developer afterwards, because you didn't answer questions promptly, when asked. It is one of the most common issues for a break down in relationships and projects ...
As Mark says "seeing early versions enables you to course correct if a feature has been implemented incorrectly or user feedback suggests a different approach."
Pitfall #7: Not reviewing your code during the build
No matter how good the development team is they will make mistakes, typo's etc because the are so close to the project. That's why it is important that someone from outside can see the wood through the trees.
Mark goes on to highlight other important considerations
1. Implement a daily or weekly stand-up meeting to clear impediments - we tend to use weekly progress reports, but be prepared to answer questions quickly to avoid delays in development.
2. Stay calm and collected
Basically, do everything you can to keep calm - even if the project gets stressful. We all want to work with people we like and who treat us with respect, so dont take your concerns out on the development team. If something is seriously going off the rails, talk to the project manager. Find a solution together. And theres always a solution if you get creative and strategic.
I have quoted Mark, almost verbatim, as he has hit the nail on the head!
3. Manage your own team dynamics
Again, Mark nails this one:
"Want to drive your development team crazy Switch up the decision-maker from one day to the next. It's amazing how quickly this misstep can cause project meltdown. If you're not a solopreneur, designate one person who will consistently communicate with the development team. Decide who makes the final call on technical issues. Keep your own internal flow clear and you'll save major time and money."
Date: 02/08/2017
7 pitfalls to avoid for non technical project managers
I read a great article this morning on linkedin - Not a coder? No problem: Concrete advice for non-technical founders, Mark McDonald - that got me thinking. His article made some excellent points, many of which I would agree with whole hearted, although it can be dependant on the working environment and budget available.
What really caught me my eye was his 7 pitfalls to avoid if you want to build a great app that are as follows:
Pitfall #1: Calling up a dev firm or contractor, describing your idea, and asking for the cost
I would support Mark's assertion that "if someone can give you an exact price tag or time-line after a five-minute phone call or a single email, they?re setting you up to fail." We are often asked if we can give a rough budget on a project after very limited discussions, during the initial sales call and simple say, we don't have enough information at this stage to furnish you with an accurate estimate that you could use for your business.
We insist on clients following our methodology that ensure we can arrive as a one or more well defined outcomes, before even attempting to propose a solution and arrive at budget.
Pitfall #2: Going too agile or too heavy
Whilst agile is all the rage, going for this approach can result in feature creep, if not managed properly; feature creep is a sure way to blow you budget and delay implementation. I am not saying agile is bad, per se, but it does have it's disadvantages and if you don't understand them, then don't fall for technical jargon like agile, scum, waterfall ...
Worth noting that Mark makes some excellent comments about other things to consider, like security, performance and maintainability! Agile code can get messy of not managed properly, with constant changes and updates.
Pitfall #3: Fully delegating your project requirements
Requirements capturing is essentially to the knowledge transfer between the development team and your business. It's essential to take an active role in this, as you need to allow the development team / analyst to ask questions to establish the issues and outcomes (see methodology).
We love this stage of a project, as it is when we can truly challenge your businesses beliefs / concepts. It's like behaving like a petulant child and asking "why" (perhaps that's why we love it so much).
Pitfall #4: Failure to prototype
Within the SME environment, most businesses can't afford prototyping, but ask for wire frames instead and make sure you really understand the specification. You should be able to use it to ru through different situations to ensure the proposed appraoch can manage all the exceptions. Having said that, bare in mind, if a system is able to cope with every exception, it will come with a price tag. Work out which exceptions can be managed outside a solution, if the cost is too high.
If you need prototypes for more complex solutions, expect to pay for them.
Essentially, the later you realise an assumption is incorrect the more it will cost. It's therefore better to challenge everything as early as possible, hopefully whilst still on the drawing board.
Pitfall #5: One-dimensional product testing
Ensure User Acceptance Testing (UAT) is planned. If you don't know how to do this ask your software house for testing procedures and / or hire a 3rd party to help you. It is one of your main responsibilities and you need to make sure you understand what these are. Don't under estimate how much time this takes.
As Mark says, "If the code is sound, the app should work", but don't assume anything, developers are not mind readers and certainly don't have crystal balls.
Pitfall #6: Waiting until the end of the project to see working software
These days, we work primarily on web based solutions, so rolling out an update is relatively easy (although not always the case). We would recommend you agree milestones with your developers and ask for a beta version of your software when each milestone is reached.
Whilst it is tempting to them flood the development teams in box with feedback, trust me, developers hate it. Try to organise feedback and liaise with the development team's project manager on who, what, when should be fed back to the team.
It's also imperative that your team fully engage in projects from start to finish. We know you are busy, we all are, but don't slope shoulders and then blame the developer afterwards, because you didn't answer questions promptly, when asked. It is one of the most common issues for a break down in relationships and projects ...
As Mark says "seeing early versions enables you to course correct if a feature has been implemented incorrectly or user feedback suggests a different approach."
Pitfall #7: Not reviewing your code during the build
No matter how good the development team is they will make mistakes, typo's etc because the are so close to the project. That's why it is important that someone from outside can see the wood through the trees.
Mark goes on to highlight other important considerations
1. Implement a daily or weekly stand-up meeting to clear impediments - we tend to use weekly progress reports, but be prepared to answer questions quickly to avoid delays in development.
2. Stay calm and collected
Basically, do everything you can to keep calm - even if the project gets stressful. We all want to work with people we like and who treat us with respect, so dont take your concerns out on the development team. If something is seriously going off the rails, talk to the project manager. Find a solution together. And theres always a solution if you get creative and strategic.
I have quoted Mark, almost verbatim, as he has hit the nail on the head!
3. Manage your own team dynamics
Again, Mark nails this one:
"Want to drive your development team crazy Switch up the decision-maker from one day to the next. It's amazing how quickly this misstep can cause project meltdown. If you're not a solopreneur, designate one person who will consistently communicate with the development team. Decide who makes the final call on technical issues. Keep your own internal flow clear and you'll save major time and money."
Date: 02/08/2017
7 pitfalls to avoid for non technical project managers
I read a great article this morning on linkedin - Not a coder? No problem: Concrete advice for non-technical founders, Mark McDonald - that got me thinking. His article made some excellent points, many of which I would agree with whole hearted, although it can be dependant on the working environment and budget available.
What really caught me my eye was his 7 pitfalls to avoid if you want to build a great app that are as follows:
Pitfall #1: Calling up a dev firm or contractor, describing your idea, and asking for the cost
I would support Mark's assertion that "if someone can give you an exact price tag or time-line after a five-minute phone call or a single email, they?re setting you up to fail." We are often asked if we can give a rough budget on a project after very limited discussions, during the initial sales call and simple say, we don't have enough information at this stage to furnish you with an accurate estimate that you could use for your business.
We insist on clients following our methodology that ensure we can arrive as a one or more well defined outcomes, before even attempting to propose a solution and arrive at budget.
Pitfall #2: Going too agile or too heavy
Whilst agile is all the rage, going for this approach can result in feature creep, if not managed properly; feature creep is a sure way to blow you budget and delay implementation. I am not saying agile is bad, per se, but it does have it's disadvantages and if you don't understand them, then don't fall for technical jargon like agile, scum, waterfall ...
Worth noting that Mark makes some excellent comments about other things to consider, like security, performance and maintainability! Agile code can get messy of not managed properly, with constant changes and updates.
Pitfall #3: Fully delegating your project requirements
Requirements capturing is essentially to the knowledge transfer between the development team and your business. It's essential to take an active role in this, as you need to allow the development team / analyst to ask questions to establish the issues and outcomes (see methodology).
We love this stage of a project, as it is when we can truly challenge your businesses beliefs / concepts. It's like behaving like a petulant child and asking "why" (perhaps that's why we love it so much).
Pitfall #4: Failure to prototype
Within the SME environment, most businesses can't afford prototyping, but ask for wire frames instead and make sure you really understand the specification. You should be able to use it to ru through different situations to ensure the proposed appraoch can manage all the exceptions. Having said that, bare in mind, if a system is able to cope with every exception, it will come with a price tag. Work out which exceptions can be managed outside a solution, if the cost is too high.
If you need prototypes for more complex solutions, expect to pay for them.
Essentially, the later you realise an assumption is incorrect the more it will cost. It's therefore better to challenge everything as early as possible, hopefully whilst still on the drawing board.
Pitfall #5: One-dimensional product testing
Ensure User Acceptance Testing (UAT) is planned. If you don't know how to do this ask your software house for testing procedures and / or hire a 3rd party to help you. It is one of your main responsibilities and you need to make sure you understand what these are. Don't under estimate how much time this takes.
As Mark says, "If the code is sound, the app should work", but don't assume anything, developers are not mind readers and certainly don't have crystal balls.
Pitfall #6: Waiting until the end of the project to see working software
These days, we work primarily on web based solutions, so rolling out an update is relatively easy (although not always the case). We would recommend you agree milestones with your developers and ask for a beta version of your software when each milestone is reached.
Whilst it is tempting to them flood the development teams in box with feedback, trust me, developers hate it. Try to organise feedback and liaise with the development team's project manager on who, what, when should be fed back to the team.
It's also imperative that your team fully engage in projects from start to finish. We know you are busy, we all are, but don't slope shoulders and then blame the developer afterwards, because you didn't answer questions promptly, when asked. It is one of the most common issues for a break down in relationships and projects ...
As Mark says "seeing early versions enables you to course correct if a feature has been implemented incorrectly or user feedback suggests a different approach."
Pitfall #7: Not reviewing your code during the build
No matter how good the development team is they will make mistakes, typo's etc because the are so close to the project. That's why it is important that someone from outside can see the wood through the trees.
Mark goes on to highlight other important considerations
1. Implement a daily or weekly stand-up meeting to clear impediments - we tend to use weekly progress reports, but be prepared to answer questions quickly to avoid delays in development.
2. Stay calm and collected
Basically, do everything you can to keep calm - even if the project gets stressful. We all want to work with people we like and who treat us with respect, so dont take your concerns out on the development team. If something is seriously going off the rails, talk to the project manager. Find a solution together. And theres always a solution if you get creative and strategic.
I have quoted Mark, almost verbatim, as he has hit the nail on the head!
3. Manage your own team dynamics
Again, Mark nails this one:
"Want to drive your development team crazy Switch up the decision-maker from one day to the next. It's amazing how quickly this misstep can cause project meltdown. If you're not a solopreneur, designate one person who will consistently communicate with the development team. Decide who makes the final call on technical issues. Keep your own internal flow clear and you'll save major time and money."
Date: 02/08/2017
7 pitfalls to avoid for non technical project managers
I read a great article this morning on linkedin - Not a coder? No problem: Concrete advice for non-technical founders, Mark McDonald - that got me thinking. His article made some excellent points, many of which I would agree with whole hearted, although it can be dependant on the working environment and budget available.
What really caught me my eye was his 7 pitfalls to avoid if you want to build a great app that are as follows:
Pitfall #1: Calling up a dev firm or contractor, describing your idea, and asking for the cost
I would support Mark's assertion that "if someone can give you an exact price tag or time-line after a five-minute phone call or a single email, they?re setting you up to fail." We are often asked if we can give a rough budget on a project after very limited discussions, during the initial sales call and simple say, we don't have enough information at this stage to furnish you with an accurate estimate that you could use for your business.
We insist on clients following our methodology that ensure we can arrive as a one or more well defined outcomes, before even attempting to propose a solution and arrive at budget.
Pitfall #2: Going too agile or too heavy
Whilst agile is all the rage, going for this approach can result in feature creep, if not managed properly; feature creep is a sure way to blow you budget and delay implementation. I am not saying agile is bad, per se, but it does have it's disadvantages and if you don't understand them, then don't fall for technical jargon like agile, scum, waterfall ...
Worth noting that Mark makes some excellent comments about other things to consider, like security, performance and maintainability! Agile code can get messy of not managed properly, with constant changes and updates.
Pitfall #3: Fully delegating your project requirements
Requirements capturing is essentially to the knowledge transfer between the development team and your business. It's essential to take an active role in this, as you need to allow the development team / analyst to ask questions to establish the issues and outcomes (see methodology).
We love this stage of a project, as it is when we can truly challenge your businesses beliefs / concepts. It's like behaving like a petulant child and asking "why" (perhaps that's why we love it so much).
Pitfall #4: Failure to prototype
Within the SME environment, most businesses can't afford prototyping, but ask for wire frames instead and make sure you really understand the specification. You should be able to use it to ru through different situations to ensure the proposed appraoch can manage all the exceptions. Having said that, bare in mind, if a system is able to cope with every exception, it will come with a price tag. Work out which exceptions can be managed outside a solution, if the cost is too high.
If you need prototypes for more complex solutions, expect to pay for them.
Essentially, the later you realise an assumption is incorrect the more it will cost. It's therefore better to challenge everything as early as possible, hopefully whilst still on the drawing board.
Pitfall #5: One-dimensional product testing
Ensure User Acceptance Testing (UAT) is planned. If you don't know how to do this ask your software house for testing procedures and / or hire a 3rd party to help you. It is one of your main responsibilities and you need to make sure you understand what these are. Don't under estimate how much time this takes.
As Mark says, "If the code is sound, the app should work", but don't assume anything, developers are not mind readers and certainly don't have crystal balls.
Pitfall #6: Waiting until the end of the project to see working software
These days, we work primarily on web based solutions, so rolling out an update is relatively easy (although not always the case). We would recommend you agree milestones with your developers and ask for a beta version of your software when each milestone is reached.
Whilst it is tempting to them flood the development teams in box with feedback, trust me, developers hate it. Try to organise feedback and liaise with the development team's project manager on who, what, when should be fed back to the team.
It's also imperative that your team fully engage in projects from start to finish. We know you are busy, we all are, but don't slope shoulders and then blame the developer afterwards, because you didn't answer questions promptly, when asked. It is one of the most common issues for a break down in relationships and projects ...
As Mark says "seeing early versions enables you to course correct if a feature has been implemented incorrectly or user feedback suggests a different approach."
Pitfall #7: Not reviewing your code during the build
No matter how good the development team is they will make mistakes, typo's etc because the are so close to the project. That's why it is important that someone from outside can see the wood through the trees.
Mark goes on to highlight other important considerations
1. Implement a daily or weekly stand-up meeting to clear impediments - we tend to use weekly progress reports, but be prepared to answer questions quickly to avoid delays in development.
2. Stay calm and collected
Basically, do everything you can to keep calm - even if the project gets stressful. We all want to work with people we like and who treat us with respect, so dont take your concerns out on the development team. If something is seriously going off the rails, talk to the project manager. Find a solution together. And theres always a solution if you get creative and strategic.
I have quoted Mark, almost verbatim, as he has hit the nail on the head!
3. Manage your own team dynamics
Again, Mark nails this one:
"Want to drive your development team crazy Switch up the decision-maker from one day to the next. It's amazing how quickly this misstep can cause project meltdown. If you're not a solopreneur, designate one person who will consistently communicate with the development team. Decide who makes the final call on technical issues. Keep your own internal flow clear and you'll save major time and money."
Date: 02/08/2017
7 pitfalls to avoid for non technical project managers
I read a great article this morning on linkedin - Not a coder? No problem: Concrete advice for non-technical founders, Mark McDonald - that got me thinking. His article made some excellent points, many of which I would agree with whole hearted, although it can be dependant on the working environment and budget available.
What really caught me my eye was his 7 pitfalls to avoid if you want to build a great app that are as follows:
Pitfall #1: Calling up a dev firm or contractor, describing your idea, and asking for the cost
I would support Mark's assertion that "if someone can give you an exact price tag or time-line after a five-minute phone call or a single email, they?re setting you up to fail." We are often asked if we can give a rough budget on a project after very limited discussions, during the initial sales call and simple say, we don't have enough information at this stage to furnish you with an accurate estimate that you could use for your business.
We insist on clients following our methodology that ensure we can arrive as a one or more well defined outcomes, before even attempting to propose a solution and arrive at budget.
Pitfall #2: Going too agile or too heavy
Whilst agile is all the rage, going for this approach can result in feature creep, if not managed properly; feature creep is a sure way to blow you budget and delay implementation. I am not saying agile is bad, per se, but it does have it's disadvantages and if you don't understand them, then don't fall for technical jargon like agile, scum, waterfall ...
Worth noting that Mark makes some excellent comments about other things to consider, like security, performance and maintainability! Agile code can get messy of not managed properly, with constant changes and updates.
Pitfall #3: Fully delegating your project requirements
Requirements capturing is essentially to the knowledge transfer between the development team and your business. It's essential to take an active role in this, as you need to allow the development team / analyst to ask questions to establish the issues and outcomes (see methodology).
We love this stage of a project, as it is when we can truly challenge your businesses beliefs / concepts. It's like behaving like a petulant child and asking "why" (perhaps that's why we love it so much).
Pitfall #4: Failure to prototype
Within the SME environment, most businesses can't afford prototyping, but ask for wire frames instead and make sure you really understand the specification. You should be able to use it to ru through different situations to ensure the proposed appraoch can manage all the exceptions. Having said that, bare in mind, if a system is able to cope with every exception, it will come with a price tag. Work out which exceptions can be managed outside a solution, if the cost is too high.
If you need prototypes for more complex solutions, expect to pay for them.
Essentially, the later you realise an assumption is incorrect the more it will cost. It's therefore better to challenge everything as early as possible, hopefully whilst still on the drawing board.
Pitfall #5: One-dimensional product testing
Ensure User Acceptance Testing (UAT) is planned. If you don't know how to do this ask your software house for testing procedures and / or hire a 3rd party to help you. It is one of your main responsibilities and you need to make sure you understand what these are. Don't under estimate how much time this takes.
As Mark says, "If the code is sound, the app should work", but don't assume anything, developers are not mind readers and certainly don't have crystal balls.
Pitfall #6: Waiting until the end of the project to see working software
These days, we work primarily on web based solutions, so rolling out an update is relatively easy (although not always the case). We would recommend you agree milestones with your developers and ask for a beta version of your software when each milestone is reached.
Whilst it is tempting to them flood the development teams in box with feedback, trust me, developers hate it. Try to organise feedback and liaise with the development team's project manager on who, what, when should be fed back to the team.
It's also imperative that your team fully engage in projects from start to finish. We know you are busy, we all are, but don't slope shoulders and then blame the developer afterwards, because you didn't answer questions promptly, when asked. It is one of the most common issues for a break down in relationships and projects ...
As Mark says "seeing early versions enables you to course correct if a feature has been implemented incorrectly or user feedback suggests a different approach."
Pitfall #7: Not reviewing your code during the build
No matter how good the development team is they will make mistakes, typo's etc because the are so close to the project. That's why it is important that someone from outside can see the wood through the trees.
Mark goes on to highlight other important considerations
1. Implement a daily or weekly stand-up meeting to clear impediments - we tend to use weekly progress reports, but be prepared to answer questions quickly to avoid delays in development.
2. Stay calm and collected
Basically, do everything you can to keep calm - even if the project gets stressful. We all want to work with people we like and who treat us with respect, so dont take your concerns out on the development team. If something is seriously going off the rails, talk to the project manager. Find a solution together. And theres always a solution if you get creative and strategic.
I have quoted Mark, almost verbatim, as he has hit the nail on the head!
3. Manage your own team dynamics
Again, Mark nails this one:
"Want to drive your development team crazy Switch up the decision-maker from one day to the next. It's amazing how quickly this misstep can cause project meltdown. If you're not a solopreneur, designate one person who will consistently communicate with the development team. Decide who makes the final call on technical issues. Keep your own internal flow clear and you'll save major time and money."
Date: 02/08/2017
