Category Archives for "How-to guides"
Welcome back to the Greyloud University Course, where we pass on the benefit of our huge experience in successful software development.
You’re nearly there now, with an application you can deploy and/or sell – even rent in an SAAS configuration – whatever your plan is. There’s just one final hurdle to get to the status of ‘User Acceptance Confirmed’ in the software development lifecycle – making sure that it really is what you want.
This is the last of my posts in the series ‘How to Ensure Software Project Success’ and in this post about User Acceptance Testing (‘UAT’), I will be outlining how you can run an efficient and effective UAT process to ensure that the approved version should at least be the minimum viable product (‘MVP’) for you. Your development team has told you that the software has successfully completed their QA process.
• A production environment is built
• The UAT team is mobilised
• The UAT team executes the UAT plan
• Issues and defects are recorded, analyzed and categorized
• The software is formally accepted by you
Let’s look at each of these in more detail.
Depending on your application and architecture this may be a simulated production environment (for example using simulated connections to a credit card merchant service – called a ‘stub’) or a fully live environment (with the exception that it would not be accessible to your full target user community). Some if these factors will be accounted for in the User Acceptance Test Plan, where the UAT environment should be described in detail. For example, a typical web application to be tested might reside in a subdomain of your main site during the UAT process.
You will need to have your Users (maybe not all the Stakeholders, but most of them) represented on the test team, with a set of tests (‘scripts’) to carry out, including representative test data – which you may already have prepared and supplied to the development team to assist them with their own testing. The test scripts will be based on the User Stories that were developed in the earlier stages of the project.
This will usually be done with a Business Analyst and Development Team Leader close to provide test support. Executing the test scripts will be done following an overall test plan with sequencing which follows the business processes. Depending on your application, there will be a range of types of testing: functional, non-functional, integration, performance, stress and so on. It is essential that one person is responsible for managing the UAT.
The UAT team will need a database or spreadsheet to record the test results and identify defects/test failures with a severity level – usually Critical, Moderate and Low severity. Issues should be discussed with the Business Analyst and Developer Lead as they are identified. Some will simply be misunderstandings either in design or operation, but these should be few in number. Others may be more serious – and even fewer in number, but rarely zero.
Certainly there should be no ‘show stoppers’ at this stage. Some ‘patches’ – updates – may be required to the software during this process, depending on the issues at hand. Other issues may be scheduled for inclusion in the next version release or ‘maintenance update’. Whether you use a smartphone, tablet or desktop yourself, you will certainly be familiar with the software update (fixes, small functional increments) and upgrade (significant functional and non-functional improvements) processes.
At the end of the UAT process, you will take a long hard look at the results and then decide whether the software meets your expectations for the MVP. Be realistic and pragmatic – not everything will be perfect at this time, but there should be a clear plan to address any issues. You might consider overall acceptance criteria as being:
• No showstoppers (critical issues), fewer than 3 moderate severity issues and less than 20 low severity (or cosmetic) issues.
Setting these criteria depends very heavily on the type of application. For example, if you employ all the users yourself and there are relatively few of them, then you might be more relaxed about issues than if your app was being exposed to 10,000 public users on day 1 when errors could have huge reputational and business impact. Each case is unique and you will need to weigh up the pros and cons as they relate to your business needs.
So, you have now formally accepted the application, probably with an agreed plan to fix some issues in a maintenance update soon after the first formal release – the cutover to the live operational application, Version 1. This version will be in a maintenance phase as far as your development partner is concerned, but Phase n+1 – the next upgrade – may already be taking shape, building in more functionality – the ‘Should Haves’ that didn’t make it into the earlier version.
I’ve now come to the end of this series and you should have a reasonable understanding of ‘How to Ensure Software Project Success’. I’ve only skimmed the surface of the SDLC and project processes but if you follow my advice then you should get what you want at the end of the project.
Obviously there is a lot more behind these steps, and experienced professionals are essential for operating them effectively to deliver a successful outcome. And, if you are looking for an effective, efficient and agile project partner, then please contact us today.
In any case, be sure to follow our blog and learn more tips and techniques for successful software development.
Welcome back to the GreyLoud University Course on ‘How to Ensure Software Project Success’ where we will pass on all our successful project experience to help you achieve your software application vision.
In this, the sixth article in the series, I will be covering the Main Development Phase. In the previous phase you reviewed the prototype and firmed up the Plan, Technology and Resources. Now, at the end of this phase during which the system is built, your application will have reached the state of ‘ready for user acceptance testing’ in its SDLC (‘Software Development Life Cycle’). The final crystallization of your vision is about to happen!
The main activities in this phase are:
• Finalizing the User screens
• Building the functionality in components and modules
• Testing at the component and module level
• Preparing the User & support documentation/collateral
• Formal QA to confirm the software is ready for client acceptance testing
Let’s look at them in a bit more detail:
So far you have walked through low-fidelity and high fidelity screens in previous stages. Now screens are hardened up and more detailed functionality is built behind them – maybe the finicky calculation and display of sales tax, or some clever text analysis – even facial recognition if you are building say, an avatar creation app.
This is definitely the point at which What You See Is What You Get. There will be opportunities to make changes after this point, but unless they are defect fixes you will have to take the pain of delay and additional cost or wait until the next version release to make the changes.
Agile projects (the vast bulk of modern day development) are run using sprints, modules and milestones and these will be clearly defined during this stage. The sprint is a spurt of software development with limited objectives when components (discrete pieces of software functionality) are built and assembled into modules (blocks of functionality such as an account sign-up module). Each sprint aims to achieve its objectives within a timebox. Milestones do not move – unfinished work is carried forward in a backlog report and re-prioritised in the next sprint.
What this means is that you should not expect 100% completion of the plan – but you should expect the really important work to be completed during each sprint. For example, all the ‘Should Have’ requirements may not be met in a given sprint, but will be built later.
‘Don’t reinvent the wheel’ is a good old proverb and in software development it has its place – ‘re-usable code’ is the norm. Why build a content management system when there are plenty of ‘free’ systems available already? Inevitably, some code will have to be built and even ‘free’ components stitched together to achieve your vision – but the expertise required to do that successfully is huge.
In agile projects, the programmer will be told to develop a piece of software using a specific software technology (such as java or php) and to ensure that the code passes a specific set of unit tests – the lowest level of testing. For example, these might include ‘verify that credit card number input from the account sign-up screen matches the correct 16 digit number format’. When the components are assembled into modules, their correct integration must also be tested.
Then there is performance testing – if a credit card check takes too long the user might lose interest – and a customer is lost. There are many other kinds of testing, but in all testing early defect detection is essential to a successful software project.
Of course, with a well-run agile project, the approach to requirements gathering, technical design and iteration should mean that quality is ‘designed in’, minimizing defects. That is why an experienced development team is essential.
Nowadays, hard copy manuals are rarely issued – they are out of date even before printing is finished. Do you remember the last smartphone you bought? You were lucky if you had a printed Quick Start Guide. Nevertheless, today’s tech products are complex and need extensive ‘documentation’ and much of that is provided online. In the Requirements Gathering stage the forms of help provision will have been agreed – web pages, wikis, FAQs, forums and a support desk to suit your planned operational budget and to meet your planned customer satisfaction levels.
And it’s at this time that the web pages, wikis and FAQs will be created and initially populated. A smart software partner will be able to convert much of the user story content and technical design documentation into ‘help’ pages. Maybe you plan to outsource the support function and not run it yourself, but either way the people that have to resolve customer problems will need a thorough understanding of the application and detailed support collateral to help them. Bad support can kill even a great product, so building this collateral is critical.
Now, at the end of this phase, the development manager should be able to tell you that the software is ready for user acceptance testing. This means that it has passed all the tests that were devised to ensure that the solution meets the business and technical requirements and has met the requirements of their formal QA process.
There you have it – your software application. Or do you? Does it meet your vision? Is it at least the Minimum Viable Product (‘MVP)? Yes, you’d better check that carefully. The next phase will tell you that when you really ‘lift the hood’ in User Acceptance Testing.
It’s a key contractual stage in the software project, but if you and your development team have followed our process and worked effectively with an open, agile approach then there should be no surprises. So, make sure you read the next and final article so that you run your User Acceptance Phase efficiently and effectively, ensuring the success of your software project. Don’t miss it!
As anyone with even the slightest bit of experience in software development, even simple websites, delays and cost overruns are incredibly common. A commonly cited statistic is that 85% of IT projects overrun their budget!
While I would never claim that I can lay out a bullet-proof project management methodology in a series of blog post, there are definitely some simple mistakes you can avoid that will dramatically reduce the risks of cost and budget overruns.
With that in mind, I asked our team members here at GreyLoud, the Hong Kong based IT company what they thought the most common mistakes were that caused problems on IT projects.
I have a very high opinion of our team, but I was truly surprised at how good the points were that they brought up from their own personal experiences. I also found that people from different roles in the development team provided very different, but equally important, perspectives on what they thought the were the most common problems.
I decided that the advice they gave was so good that I would devote an entire blog post to each item. For each I have described the scenario, then offered practical steps on how to avoid the issue for both the client side (internal or external) as well as development team.
Given that the responsibility for delivering a successful project fall on the development team, I provide considerably more details in that section, including easy to follow instructions and processes that can be applied in any organization.
Without further ado I present:
I received our first tip from our Ruby on Rails Engineer Anton. Simply put, make sure that anyone giving instructions, requirements, or feedback to the development team has been authorized to make a final decision on the topic.
Imagine this scenario: A junior member of the marketing team requests changes to the design of their new website. The dev team, not knowing that this employee is not actually the person responsible for managing the website design, rebuilds the website based on the what they have been told.
When the CEO sees the result, they are shocked and angry to see that the website is completely different than what they asked for! The CEO is angry because of all the wasted time and money, and the dev team is frustrated and demoralized because they worked very hard on something that wasn’t needed!
Everyone realizes that this mistake could have easily been avoided with a little more attention to managing communications.
Make sure that you have a clear chain of command established with your project team, and make it clear to them that they should never under any circumstances give advice, instructions, or approvals unless it has been decided ahead of time they that team member is authorized to do so.
Even if a member of your team is a subject matter expert in any given field, such as design, establish a process where that person provides their input to your project owner who will then pass it to your development team. Like many SDLC best practices, it may seem like an extra step, but this is one of those situations where an ounce of prevention is worth a pound of cure.
Also, make it clear to your project manager on the dev team or IT contractor that only certain people are allowed to provide approvals and feedback, and that input from other team members must be approved by an authorized individual before any work begins.
Lastly, if you feel your project requirements are large or complex, ensure that your development partner creates and enforces a formal Communication Management Plan, which I describe in more detail in the section below.
First of all, make sure to specify in your contract or project charter that the client or project owner must designate one (and only 1) person to represent them that your team can rely on for feedback and approvals.
Under absolutely no circumstances should anyone on the software development team accept feedback from any other person without prior authorization from both the project manager and project owner.
This document will describe how messages and critical information will travel between various stakeholders and members of the project team. This is done by first describing the objectives of all information passed between team members. Some examples of communication objectives are:
Generally speaking, stakeholders and team members will fit into one of these categories:
First, define which platforms or mediums you will use to communicate information. At GreyLoud we use the popular chat tool Slack for the majority of our internal communication, as well as communication with our customers. For telepresence and remote meetings, we find that Google’s free voice and audio chat tool Hangouts is a great fit because it integrates seamlessly with Google Calendar and because it doesn’t require users to download any special software to use.
Sometimes you may have to adjust the tools your team would normally use due to internal protocols at you client, especially if they are a large company with a restrictive IT and/or regulatory compliance environment.
Additionally, you should define the documents that will be created to fulfill specific communication objectives such as:
Also, specific types of meetings such as:
At this stage you are should also be preparing your project plan, so be sure to note major communication items such as the kick off meeting, milestone reports, test cases etc. One way to do this is to create a communication matrix and attach it as an appendix to the project plan:
In the case of a large project team with a defined hierarchy or many actively involved stakeholders, it is wise to create a formal flowchart of communication and approvals that will make the communication process easier to understand for all involved.
In the final step, we will create a formalized document of all communication items in the project plan in the form of a Project Communication Action Plan. This is an expanded and detailed version of the communication matrix that includes all major communication items with the following details:
This sound like a lot of work, but lucky for you, we have included templates of all required documents of the Project Communication and much much more in our Project Plan Readiness Pack. This pack includes templates for all the major documents and information you need to assemble to drastically improve your odds of executing a successful software project.
Even if you plan on working with an outside development team (like our excellent team here at GreyLoud) fill in gout these worksheets will save you a ton of time, headaches, and money by setting you up with everything you need start building your big idea.
Welcome back to the Greyloud University course on ‘How to Ensure Software Project Success’. This course gves you the benefit of GreyLoud’s experience across many successful projects and thousands of hours of development effort. We will help you achieve your vision.
In my previous articles about we have navigated the early stages of the software development life cycle (‘SDLC’), and by now you know a bit more about gathering requirements and firming up the specification. Now we come to the prototype – something you and your stakeholders should be able to ‘touch and feel’, something that starts to bring some life to your vision.
The prototype helps build stakeholder commitment and ownership of the solution – an absolutely critical element in ensuring a successful project. Beyond that, the prototype can help uncover technical and business requirements issues before serious budget is committed to a full production build.
The prototype may only be ‘low fidelity’ – that’s jargon for ‘rough and ready’ – but it is of huge significance. Formally accepting it (maybe with some reservations) is a key change of state in the software development life cycle. When the prototype is approved, it demonstrates that:
• Technical risks have been identified and resolved
• The Business Requirements have been validated (at least at the summary level)
• Users have commented on the UX (user experience – the look and feel)
• The base specification is confirmed for the first production build
• The stakeholders have bought in to the solution
Many projects have failed simply because of incompatibility between versions of 3rd party software. Maybe the specific functionality was released but didn’t work properly. That’s just one type of technical risk, known as an external dependency. Then there are internal dependencies, cross project dependencies, performance risks (say where a mobile app struggles to perform when there is low memory availability) – the list is endless.
When the specification is firmed up, the technical risks should have been identified and there should have been solution strategies identified to eliminate or work around them. Now at the prototype stage, those solutions will need to be demonstrated. ‘Show stopper’ is a phrase that says it all. That’s a critical risk that must be resolved at the prototype stage. Ignore show-stoppers at your peril.
But there’s one other risk that can easily be overlooked – the inherent risk in your development team. Do they have the skills? Are they up to speed with the latest technology? You will certainly find out when you review the prototype.
If your application is highly innovative or uses new technology then the technical risk profile may be much higher – and this fact should be explicit. These risks should be clearly and satisfactorily addressed in the prototype. The ‘Leading Edge’ is often known as ‘The Bleeding Edge’ – and there’s good reason for that.
You have your list of approved business requirements – maybe on a spreadsheet or in a database. When reviewing the prototype you will work with a Business Analyst and should be able to confirm the presence of the required business functionality. There may be some snags that need ironing out (record them and categorise them as Critical, Moderate or Low Severity).
It is not uncommon at this time to find that nuances of functionality become apparent and that one or two requirements may need revision – remember the word iteration?
The UX is an important part of an application. For example, if you are planning to release a smartphone app linked to an e-commerce store then the ‘shopping experience’ will be important. The person who had the role of ‘remote user’ during the requirements gathering process will need to review the whole experience of using the prototype.
Of course not all detailed functionality will be present in the prototype. For example the full process of a user returning a product to your store – which hopefully would not be a common occurrence. Ensure that all your user representatives – including your support staff – have an opportunity to review and comment on the prototype. They are all part of your stakeholder community.
Working with the Business Analyst, you and your stakeholders will walk through the prototype. This is best done in a workshop environment to encourage interaction and help resolve issues speedily. If it’s a large or complex project then this walkthrough may be split into several workshops, organized by functional area – for example Supply Chain, Customer Shopping.
At the end of the Prototype review there may be some issues outstanding and your stakeholders may give qualified approval provided that a clear issue resolution plan is agreed. For example:
Prototype Issue #3: Supplier Order Screen layout does not reflect optimum layout for user input. Severity: Moderate. Resolution: Specific test issue to be created. Comment: this is a prototype only.
Once the prototype review is complete, then you will have an issues list to be addressed by the development team. Circulate this list to all the stakeholders and ask them to confirm it is accurate for the areas which they have reviewed, and that they formally approve the prototype. Depending on the issues, you may want the prototype to be adjusted or tweaked before formal approval.
It’s worth noting that what can seem to be a relatively minor technical point can have deep-seated ramifications. Usually, the issues are relatively minor but beware of any technical issues which have not been resolved.
So, your stakeholders have all confirmed the prototype and should have bought in to the solution. In larger organisations and/or with complex projects, achieving 100% buy-in can sometimes be a challenge. Managing the stakeholders can be a bit of an art, but hang to your vision of the solution – somebody has to drive progress!
In my next article I will be discussing the next critical step – Confirming the Plan, Technology and Resources. Follow us and be sure not to miss it!
Welcome back to the GreyLoud University. This is the third in my series of articles on ‘How to Ensure Software Project Success‘. By following our course you can gain the benefit of our experience across many projects and thousands of hours of development work.
Here I am going to show you how you move forward from the initial set of confirmed Solution Requirements to firm up the specification of the system or app you want to build. When I say ‘firm up’ I mean that you will add more detail to the requirements, come up with a tighter cost model (by feature), rationalize and check the prioritization of the requirements and formalize the user and system flows – and cross check. You also will need to settle on a final choice of technology option. The result will be the System Requirements Specification.
Before I do that, I’m just going to remind you that you are in an iterative process and you will very probably come round this cycle again as you learn in more depth about what you can and can’t expect to achieve in the initial build. For example, some really great features might require third party technology (such as ‘middleware’) or have a build cost which would price the final product out of the market, or which your budget will not stretch to.
Now you have the information about the solution, the cost estimates, the Business Analyst will liaise with you (the client) and will help you prioritize the requirements. This is where the Business Analyst adds more value. You are not throwing anything out at this stage, just confirming the functionality that will be built in the first version – and that it is within budget. Other functionality may be delayed until a later version.
To ensure both budget and timescales are achievable you go one step further and prioritize the functionality within the first version. In an agile ‘scrum’ development process the build is made up of a series of sprints – or development/test cycles building out functionality progressively – delivering additional features sprint by sprint. If you set clear priorities within the version 1 requirements then development snags need not cause delays – you just reschedule the ‘desirable’ items for a later stage. This means that the MVP (minimum viable product) is achievable within the timescale and you have all the ‘must have’ functionality in version 1.
In this step, you or your development partner will formalize the user and system flows – in simple terms how the user will interact with, say, the video streaming app, and how the datastream will be delivered and presented on the target platform(s). This check covers all the users, including your support desk and managers – maybe even the finance users on the billing side.
Taking a video streaming example, the broad architectural options would range from using a simple server to using a CDN (content distribution network). The options will need to be considered right through the application to the presentation layer and user interface (‘UI’) on the target platforms. These will need to be assessed with the pro’s and con’s (including risks) – and costs – being identified. If, for example, the Business Requirement is to deliver a video stream to the iPhone platform only, then there are Apple-specific options which may be simpler to implement.
Some options may be more costly initially but would enable a shorter implementation timescale. This could give you earlier benefit flow – revenue or business efficiency gains – maybe both.
This work is usually done by the ‘Technical Lead’ – the senior software engineer on the project, someone who knows that the devil is in the detail – and that the last 5% of functional nicety (say a particular ‘should have’ video catalogue view) can be the most expensive to build. This costing is usually done by estimating the amount of work involved in each piece of functionality, not forgetting that the functionality has to hang on an architectural framework which may have a cost – and that will depend on the technology to be used.
Depending on the particular project it may be that a range – ‘low’, ‘most likely’ and ‘high’ estimates will be produced, and they may be produced against a range of technology options.
All these costs are then rolled up into the final estimate.
This is a critical checkpoint, where you confirm that the user and system flows match the product vision – and that this budget is acceptable. Some changes are often made at this point – better now than later. You might have to drop one or two functional niceties from version 1 and schedule them for a later version when your app is earning its keep. However, it is at this point that you should expect to commit to a specific technology option.
So, you now you know what you will be getting (at least in version 1). Not only that – you have confirmed the content and fined tuned the solution requirements specification. You should also have an overall cost estimate for the whole project, so you know what you will be getting – and for how much.
In the next article I will be looking at the next step along the path as you discover how to ‘Ensure Software Project Success’ – when the first prototype is built.
Follow us and be sure you don’t miss it!
Welcome back to the Greyloud University where we will help you refine your idea or vision for a software application.
Hopefully, you’ve read the first in this series of Greyloud University papers (‘How to Ensure Software Project Success’) and you understand the context of a software development framework (‘SDLC’) and process; you know about the concept of iteration. In this second article of our course, I am going to cover the gathering of the Business Requirements.
This step will usually require you to work with people known as Business Analysts. You might already have them in your company already, or your development partner will have them in their team. This is a skilled area – these professionals will know how to dig behind your ideas and uncover other possibilities that you hadn’t considered. They can add real value to the final business requirements.
Where do business requirements come from – just from you, or are there other people or organizations you need to involve (the stakeholders)? Who are they, those people/organizations with a vested interest in the final product? How do you gather the Requirements, how do you sort the wheat from the chaff? And then, what’s the next step?
Who are the interested parties: Leverage the stakeholders
Who are the Stakeholders – you will need to identify them? They are key to the process of gathering the Business Requirements. Think about the vision you have of the finished software. Who will use it? Who will interact with it (even remotely, such as a smartphone user sharing a screenshot with a third party)? Who will maintain it – for example, change any configuration data either locally or at a central server – or both? Sad to say it, but even the Revenue Authorities might be a stakeholder in that you could have to provide data for them.
So, you need to compile a list of all the Stakeholders. They need not be named individuals, they could just be roles (e.g. corporate customer, personal customer) – but you will have to choose someone to represent those roles and to provide requirements from that perspective. For commercial viability and to protect your idea (your intellectual property – ‘IPR’) you may choose people within your firm to take on the role of external stakeholders. For example, your Sales Director might take on the role of Corporate Customer at this stage. Someone else might take the role of Remote Personal User. And the Revenue authorities – don’t worry, your finance manager should have that role. Get the idea?
Start building the business model: Gather the business requirements
What does a business requirement look like? Try this out:
Requirement # 1. ‘The sales manager will be required to respond to customer billing inquiries by checking the accuracy of a particular invoice on the accounting system’. Priority: Must Have.
Notice the ‘priority level’. You can use terms such as ‘Must Have’, Should Have’ and ‘Desirable’. This helps to identify what is really important and what, if there is a budget constraint, can be scheduled for a later version. Give your stakeholders something to think about – start with the vision and some suggestions. They will find it easier to build on that rather than start with a blank screen.
A small hole can sink a ship, so this is where some rigor is advisable. I recommend strict control of the Requirements. I prefer to number them and give each one an owner (usually the originator). Capture everything, don’t lose anything – there may be real nuggets buried in there.
And then there are your own requirements if you are an entrepreneur. Is it a killer app you plan? You may need to keep some requirements under wraps from all the stakeholders in the initial stages – and have watertight non-disclosure agreements in place.
You can carry out requirements gathering by email, but I would recommend Requirements Workshops, organized broadly by functional grouping – depending of course on the size of the project and the complexity of the solution. If you can’t run them in the same room then they can be done virtually using Skype or other software. Workshops save a huge amount of time as they will save time and focus the debate. Let people think freely and interact, and remember to capture everything – you don’t want to miss that one killer nugget.
There may well be cross-functional interaction which will define additional Business Requirements – e.g. ‘Requirement #27 Confirm successful transaction by linking to our billing system and return after transaction processing successful or canceled. Priority: Must Have.’
Then, don’t forget to check the competition. What they have (and don’t have) can provide you with useful input to both the Business and Technical requirements – and give you an edge. Hang on, Technical Requirements – what are they?
Nuts and bolts: Identify the technical requirements
Besides the business requirements, there will be a parallel set known as the technical requirements. These will also need to be gathered in order to help identify the technology to be used and manage the operation of the system. Many of these technical requirements will be generated from the Business Requirements. A good software partner will help you flesh these out, along with input from your technical staff. Of course, your business requirement might be to ‘provide a technical solution to screen-scraping a smartphone screen’. The technical analysts will help you clarify these requirements. These also need prioritization as they will have risk, cost and resource implications.
An example might be ‘Must be deployable to both Android and iPhone platforms’. I certainly would not consider a release to both Apple and Android platforms at the same time, so I would prioritize one or other for the first release although they are both ‘Must Have’.
Give people a picture: Produce the user stories organized by functional modules
What are User Stories? It’s simple, these are a visualization (and/or description) which describe what the end user or user of a system does or needs to do as part of his or her job function. You need to produce these for each user role you identified (remember the stakeholders, although might not have user roles within the system)?
A good software partner will help with this step. It’s very important because this helps the business analysts and development teams (in-house or external) to establish a common understanding of the how the system will work for the users.
I once worked on a retail banking project (when banks were still on the High Street) and we filmed the bank tellers at work so that we could figure out the most efficient way for them to process counter transactions with minimum hand/finger movement. This was then factored into the user stories. Of course, if you plan to change the behavior of users then you need to consider this very carefully, as there could be serious implications – as happened when Microsoft released Windows 8. The changes to the Windows user experience (‘UX’) were significant and users were unprepared – and very unhappy.
Typically, these user stories may be prepared and presented as a spreadsheet. They will be organized by functional area – ‘module’ and in timeframes – ‘epochs’.
Check you are all on the same page: Confirm understanding across stakeholders
The user stories are confirmed with the stakeholders usually at ‘walkthrough sessions’ which can be done virtually. Expect changes – re-working is a good thing at this time as it’s better to capture issues early on and save cost and time.
For the record, keep a set of minutes and ensure all stakeholders confirm them.
Closing words: The fog starts to clear
By the completion of this stage, you (and the stakeholders) should have a pretty good feel for the solution that will be built. But do remember that it is an iterative process and some revisiting may be necessary. So:
My next article will help you understand how to Firm up the Software Requirements Specification as the final vision starts to crystallize.
Perfected over the course of dozens of successful projects and tens of thousands of development hours, our process brings together all critical inputs to building great software products.
We decided to create GreyLoud University in an effort to share our hard earned lessons with the rest of the startup community, and to help our other people realize their ideas quickly and cost effectively.
Without further ado, we present Part 1 of our first GreyLoud University course and hope that you will benefit from our experience.
“The GreyLoud Guide to Software Project Management- Part 1: How to Ensure Software Project Success“
If you are thinking about starting a software development project, you should read this post and all of the other articles we have produced in our first GreyLoud University series: The GreyLoud Guide to Software Project Success. I am going to lead you through the best approach in a few easy articles. This first article will give you some overall context – and then I’ll look a bit more closely at the various stages in later articles.
I will point the way for you and keep the jargon to a minimum. Now, it may seem like a pain, but for a successful project, it’s important to understand some of the principles of the software development process. How do you make sure that you actually get the software you need from your development team or partner? A key measure is ‘best practice’. Do they follow it?
‘Best Practice’ includes developing software within a framework. A software application, whether a smartphone app or a utility billing system, follows a Software Development Life Cycle (‘SDLC’) during its conception, development, and final delivery, and during that life cycle it undergoes processes which move it through distinct ‘stages’. Understanding this framework will help you follow the path to software project success. Firstly, let’s take a look at the reasons why projects fail and how we avoid those within an SDLC.
Now, you’ve probably heard the statistic that 30% of IT projects fail and 40% of projects don’t meet their business case within one year of go-live. Rest easy, I’m not going heavy on miserable statistics – I’ll be positive. The flip side of those numbers is that 70% of projects succeed and 60% actually do meet their business case within one year. ( The Chaos Report ).
So, let’s face failure – and learn from it.
When we look at the reasons for project failure in ‘The Chaos Report’, the top ones cited are
closely followed by
Apart from Resources, all these reasons for failure are avoidable using a well-defined SDLC – with, of course, effective managers, but that’s down to you and your colleagues or to your development partner.
A structured approach matters because if all the state changes of an SDLC are followed properly then the main reasons for software development project failure are eliminated. It is not rocket science (though a structured SDLC is certainly used for space projects), and need not be bureaucratic and top heavy. In fact, it can work very well within an overall agile development approach where collaboration and flexibility are the norm.
An experienced project manager will be able to tailor the process having assessed the risks. The result should be a lean process which will build the software through MLP (minimum learnable product – a prototype) to the MVP (the minimum viable product – including all the base functionality).
At the various stages of the SDLC the development team will
There are several key stages in an SDLC, which may be more – or less – complex depending on the project. For example, if you want a simple web rtc app for your own smartphone and nothing more, then you are the only stakeholder. Or are you? What about the smartphone manufacturer, maybe even Google (who supply the Android operating system – a new release might screw your app – or even worse, brick your phone)? One way or another they should be taken into account. And the issues are not always technical – there is your phone’s service provider. It could hit you in the pocket. You don’t necessarily need to talk to them, but their perspective has to be considered.
So, the key stages of an effective SDLC are:
You need to recognize what happens in real projects – and plan for it. Each iteration will deliver a planned increment – new features, better performance and so on. This iteration process needs to be stable and repeatable as your software may go through several versions during its lifetime, as business requirements and technical requirements change – and they surely will. So, whatever the stage of the project you need to:
This iterative process is a reflection of what happened historically in successful projects, and is a key concept underlying modern agile project management approaches.
Iteration operates at a higher level of cycle too, by creating a production process which is able to continue enhancing the released product in response to an enhancement or build-out plan – or to market pressures. For example, Microsoft release a new version of Word every 1-2 years, but Facebook releases a new version of their website twice a day!.
Hopefully, you now have a feel for how you should start to prepare for a successful software project. You now understand elements of an effective SDLC in a software project and the importance of iteration whatever the technology to be employed. And, if you are planning to engage with a software development partner, you can use the information in this article as a way of assessing whether they stick to the key elements of an effective process – and whether they can deliver success for you.
In the next article I will be looking in more depth at how you identify what you really want – ‘Knowing What You Need – the Business Requirements’.