It is an ongoing question, and an area that many companies try to continuously improve. Watch and listen how Softjourn does it.
Archive for the ‘Project Management’ Category
In response to a recent article in CIO magazine, Softjourn’s Head of Software Development came up with his own top 7 wishes! Check it out and see if you agree! Thank you Anatoliy for the input to this article!!
If you have been wondering which type of outsourcing engagement model may work best for your company, Softjourn has compiled a few tips. As well a few of our developers provided their perspective on which they like better. Check it out!
This is a question I often get. I am sure you already know the answer, “It depends!!” Like many things, you can spend a little, or a lot, on a prototype. How much you spend on the prototype depends on; where you are in the validation process of your idea/new product/service, what you have already defined as being critical for your potential users and potential investors to see, and on what type of a prototype is best to develop.
But before I get in to that, the first question I usually ask is, “What does a prototype mean to you?” It means different things to different people. Officially, in software development, as in other disciplines, a prototype is an incomplete version of a final product. The objective of a prototype is to simulate only a few functions of the desired application. The owner of the prototype needs to get feedback from potential users and investors, as to the value of the solution for the market, i.e. market validation. Typically an entrepreneur has already been out talking about their service with potential users and potential investors (at least friends and family to start). They have received validation from a select group that the idea is good, they may have showed them wireframes or a presentation on the idea, but now they need to go to the next step, which is to “show” something so that the idea becomes more real to potential users and investors. Thus they can get more real feedback. They need to answer questions like; “How would the system do that?”, or “What would I do in this case, if I was using the system?” The answers to these types of questions do not make sense until users can actually “touch” something, or in the case of software, actually play with something and see how it could work. In reality a prototype should only simulate a few functions, and ideally those functions which will be those that will differentiate it from other similar existing services or solutions to the user’s problem.
Now that you know what a prototype is and what it can be used for, then you need to decide, do you really need a prototype? If your new product or service is similar to ones that already exist, and that can be viewed by others, and your differentiation is going to be based on pricing or target market or other, then maybe you do not need to create a prototype. However, if your differentiation is going to be based on unique features, you may need to validate those features. Especially if they are more complicated, you will want to simulate them in a prototype in order to get feedback that the features will make the product truly unique and that they have value in the market place. If your new service is going to be totally unique in the market, then definitely creating a prototype to validate your market is the way to go.
So if you need a prototype, what type of a prototype do you create? In broad strokes we can divide prototypes in to two categories; throwaway and evolutionary. A throwaway prototype is just that, it is created to simulate the desired features, then after market validation or after the prototype’s purpose has been outlived, it will be thrown away. If, during the use of the prototype, it was decided to go forward and develop the full service, development will start from scratch and not reuse any of the code from the prototype. An “evolutionary” prototype is one that is designed to be “built-upon”, it is intended that as the prototype is shown around, feedback is received; new features will be added to it, modified, removed, etc., until it is ready for launch as a brand new service. All code will be used, or at least that code for the features that will stay in the new service, will be used going forward. Because evolutionary prototypes are going to be used for the final real service, more time needs to be spent up front on technical design and architecture. The prototype needs to be built using the desired coding language, database, etc. If you take your budget for your prototype, you can plan that for a throwaway prototype you will be able to show more features than with an evolutionary prototype since part of the time and money for an evolutionary prototype will be spent on design and architecture. Create a throwaway prototype if you need more feedback on the idea and the target market and you need to show a lot of different features. You could end up pivoting from the original objective and market for your new service and in this way you would not have spent a lot of money architecting something that may never get used, or that you find there is no market for. Go for developing an evolutionary prototype if you are very very certain of your idea. Maybe you came from that industry and have already done a lot of validation of the idea and you know the concept won’t change that drastically. It is a good idea to also have the budget available to fund ongoing development of an evolutionary prototype to add new features or take them away as more and more potential users look at your system (keep in mind that the first prototype is going to be light on functionality).
All of the above brings me back finally to the original question, “What does it cost to build a prototype?” Typical budgets for prototypes range from $3,000 to $7,000. As an entrepreneur you are not necessarily going to want to spend more than that on a prototype. Your objective is to get something out there fast and get moving to the next step in validating your idea. You could always, of course, spend much more on the development of more simulated features, but really concentrate on those that differentiate you the most, not on everything. A throwaway prototype can fall anywhere in that price range, the higher the pricing, the more functionality that can be simulated or the more effort put in to design, if the user interface is extremely key to helping you validate your market. An evolutionary prototype will fall towards the higher end only, because of the need to do the technical design and architecture. Typical timelines for creating prototypes are 2-3 weeks to 4-5 weeks. There will typically be 2-3 iterations before you get to your final prototype. Also expect to really engage with the team developing your prototype, both on UI, on refining the features to be simulated and on review/feedback cycles.
Congratulations are due to our web team on the launch of the new web portal for Ukraine’s National Cadastre System! A big thank you to Maryna T., for all of her work as Product Owner for the project. Maryna spent a lot of time on site at Ukraine’s State Agency of Land Resources, working with many different people to understand their objectives and priorities. She writes about her experience in Softjourn’s May newsletter which will be posted shortly. Many thanks also to Yevgeniy V., for being a great leader and PM during all three phases of the project. And of course, GREAT JOB to the rest of the team! Read more about this project here: http://www.softjourn.com/joomla-web-developers-ukraine
I do not 100% agree that the issue of distance no longer exists; however I agree time zones are here to stay! According to the authors of, “I’m working while they’re sleeping”, we do not have a problem communicating across distances because there are so many tools available to ease this process, however, issue of differences in time is still there and will remain. Even some of the evidence the authors present in the book, on team dispersion versus productivity, refutes the claim that the issues of working across distances are all in the past. This part I did not get….. One of the examples given was the issues teams experience, even when they are located in the same building, efficiency still goes down……probably due to people thinking that less effort is needed if you are in the same building. I think we have all seen this, even with a difference in floors, in the same building, there tends to be knowledge on some floors that has not been dispersed to people on other floors. However, the authors gloss over this issue for the book, stating there are no more issues across distances, but rather concentrate on talking about the issues caused by time zone differences.
This is the third book which Erran Carmel has been an author on, which I have reviewed. Therefore I was anxious to take a closer look at it. For me it was the first book that I have seen, that concentrates chiefly on time zone differences. I am vacillating as to who is the best targeted audience for this book? After reading through, I am thinking it would be most beneficial to those who have already worked, at least once, with teams across many time zones. The situations discussed would be very familiar and it would be easier to pick up tips of what to do next time, than to pick out planning tips that could be used for your first “distributed across multiple time zones” team. The authors seem to elude to this as well, that time zone differences and how to deal with them, is not a concern until it becomes a problem; i.e. not usually seen as an area to talk about upfront when starting a team. However, I do see this as a book that could be very useful for the person who is looking to become, or has been tagged to become the “global liaison”, as the author’s refer to the person who works between teams in different locations (this person could also be the product manager, project manager, project coordinator, or have a host of other titles).
The book itself is broken up in to three sections: The Fundamentals, Time Zone strategy, and the last section is titled, “Time and a Half”. I had to laugh at the comment in the section on fundamentals, about outcomes, and that, “The advantage of distributed work is that you can blame distributed work for the project being late……”. An excellent point is made, that bears repeating, that we need to understand when coordination is truly necessary. One team may be effectively coordinated but at an extraordinary cost, thereby driving team performance outcomes down. A good example of this is when a coordinator (or global liaison) manages too few people, not an optimal number; the cost is high and the performance is lower than it could be.
An oft repeated topic in books related to virtual teams, or global team management, and frequent topic of conversation among project managers is a discussion of the pros and cons of complete time overlap for a team, versus receiving at least some benefit from only having some overlap (not in the follow the sun type of way or round the clock meaning, but just two or three hours of overlap). Working during the same time, of course provides the widest window for same-time interaction, but it also leads to more interruptions. The authors add further research to this discussion that gives food for thought. Having some kind of a time difference may force the team to establish better practices, which includes having some quiet time for individual team members. This is where the question comes in. What is better for the team members? All knowledge workers and team members will have an opinion on this. It is seen as a benefit of distance that less time overlap means less interruptions, or at least interruptions can be more planned. It is a well-known fact that interruptions cut down on productivity, it is harder to get back to what you were doing before after every interruption. However, the book contains interesting research that shows that 44% of the interruptions we face during a day are self-imposed (checking our email, checking Facebook, getting a cup of coffee or tea, playing a game of ping pong (one of my favorite interruptions), etc.), and that actually with interruptions, we tend to be more productivity. We tend to try and make up for interruptions and work faster. However, allowing for these interruptions does tend to raise our stress levels. So it seems that because of 44% of our daily interruptions are self-imposed, we tend to work harder, and be more productive. However then the other question I have is, if 56% of our interruptions are not self-imposed, do we work harder to make up for those interruptions as well? The experiments do point to the fact that the social interruptions may be very beneficial (whether virtual or face to face) for generating ideas, or to get a break from a difficult problem and come back with a fresh head and perhaps a new way of looking at the problem. This I think we all know from water cooler or kitchen discussions which pop up during the day and that can be very helpful. Appendix D continues the discussion on the science of interruptions and is worth the read.
You will want to pay attention to the time zone strategies introduced, some of which are familiar; Follow-the-Sun, Round-the-clock, and real-time simulated co-location. As well as the six time-zone configurations that are discussed. The authors discuss examples to determine what works best for what type of activities; i.e. can software development really be done using a follow-the-sun strategy, i.e. every shift is handing over work to the next shift. As many people know in this industry, this strategy has been tried and tried again. Technically it can work in certain situations and with the right structure; i.e. the right combination of developer sites, to reviewer sites, so one location does not become a bottle neck. The authors discuss examples of companies which have tried this method; what worked, what did not work, and how they eventually tried to sort things out.
A benefit to reading the book is to pay attention to the benefits and target activities for each time zone strategy. For example according to the authors, the Follow-the-sun strategy, which involves; unfinished work that is handed off to the next sit on a daily basis, it is about speed, sites are very dependent on each other. Works best for activities like: Rapid prototyping – creative task, with serious coordination.
However, I thought it was very interesting that based on the examples used, the authors drew the conclusion that with follow-the-sun quality goes down. The reasons being that the tasks are more complicated, maybe there are more questions, and the team cannot ask them during the day, so they are guessing, and guessing wrong. What I am wondering is, especially in a situation like rapid prototyping, can any benefit be gained by a follow-the-sun methodology? Is there any benefit to having the team work in a silo (at least for several hours in a day)? Would you, or could you get something unexpected, that turns out to be better than what was planned for? Instead of direction coming all from one location or one source, ideas come from many locations with different backgrounds and differnet takes on the project, which could make for a better product in the end? I am wondering if this theory has been tested. I suppose it has somewhere, just need to dig for the results. I am also curious if the “reduction in quality” that was sighted for follow-the-sun, has been full researched? What do they mean by quality? Sometimes it means the product was not done the way I would have done it. If you are going to be working on something like rapid prototyping, global teams should have a lot of autonomy to make decisions on their own. That seems the only way to get the full benefit.
It was also good to note, and get straightened out that may global teams think they do the follow-the-sun approach, but if they are doing any part of a parallel approach or phase approach, then they are not really taking advantage of time zones. i.e. this location is working on this independently, and this one is working on this independently. The workers just happen to spread across the globe. That is not true follow-the-sun. Another key of course to making follow-the-sun really work, is to have the right development methodology. The authors believe that agile works the best- short time bursts, iterations. I think the key here is that the team is big enough that some function is always being fully developed and fully tested each day and can be delivered continuously. In this way the different time zones can concentrate on development, testing, and review and acceptance. The authors make a good note for agile development which is that personal time-boxing curbs perfectionist tendencies, procrastination and prevents an individual from over committing to a task.
Finally in the last part of the book, the authors offer two radical options for handling time zones. The first strategy is to establish a 24 hour culture within a company. People who work all hours are supported, but it is important that anyone in the company realizes that at any time they may have to work night or day, depending on when the client is working. The question is, can this be sustained? The second radical strategy is to engage in Real-time simulated co-location (RTSC) (of course this one also really requires the 24 hour culture…….). For this strategy, always on audio/video is required, something similar to Cisco’s Telepresence. Also needed is an awareness technology such as a shared dashboard to look at key project data. Co-located teams work in the same room, where developers work together, elbow to elbow. The rule for co-location strategy is (near) perfect time overlap. Video overlap screens let anyone look at who else is working. Then you can just walk up the screen and call the person you need to talk with. I think some teams would like this, to be able to see who is working and to know if they can bother that person at that moment with something. Would it lead to more spontaneous discussion like a discussion the kitchen, I am not sure. Also, what does this feeling of being “watched” do to the developers? It is one thing to be in the same room with people, where everyone is getting in to their own zone, but to know that in the back of your mind, a camera is on you……not sure. It may seem more like something to be used by management, just to see that people are working, rather than as a tool for more collaboration. But I think this perception will be changing. In any case, both of these strategies require a literal 24 hour culture, and who is going to be the major time shifters? That will be a power struggle between locations, and between countries. So I am not sure either one of these strategies, as described in the book, would be the answer for the long term. I do agree though, because of technology improvements we will continue to move in the direction of being able to walk up to a wall and seeing who is working thousands of miles away and connecting with them immediately (as opposed to what we now which is ping them in skype or call their phone and see if they have some time to talk).
Thank you Kostya for your insights in to Sharepoint; what it is best for, etc. Also thank you to Olga for interviewing Kostya and providing this write-up.
Ticket scanning at the movies in Ukraine!
We recently developed a new iOS ticket scanning application for one of the cinema networks in Ukraine! Thank you to Yevgen V., Denys K. and Vitaliy I. for the great job they did!
This app is using the Linea Pro scanning device, along with an ipod touch (it also works with iphones), from Infinite Peripherals.
Infinite Peripherals also has a new scanning/credit card swiping device that can be used with ipads! Here is an example of how it is being used.
The answer is VERY!! I cannot stress it enough that a daily check point is needed for the majority of software development projects and this becomes even more important when part of that development or work is done remotely.
Many companies already use the agile development methodology and have daily stand up meetings, in other words, what did I work on yesterday, what am I working on today, what issues, if any, am I having that I need help with. These are really standard questions that have been asked in status meetings for decades, now this process is called the agile methodology….but that is another story. However, there is something more important happening during these meetings. The possibility for real time discussion! Let’s say for example that this status, instead of being in real time, is given via email, or posted in an online collaboration tool. That’s great, but if someone writes in their status, worked on item #3768. Ok, if you are the manager of the team, yes of course you know what item #3768 is, but do you have the opportunity to discuss with the developer, how long it will take to finish that item, or what solution are you using for that issue, or to ask other questions. Yes you can do this via email, but no matter what that will take MORE time that just a quick conversation in real time, and the one issue most managers will say is that they never have enough time. So it continues to confound me why some managers do not want to do daily real time discussions?
Some of the reasons most often given include:
- I don’t want to get up that early or stay up that late. I can definitely understand that. But for many situations, if the time difference is 10 hours, for example, one side can get up a bit earlier, or one side can stay a bit later at work, and it is not that inconvenient. When you get in to fifteen hours’ time difference things can get a bit more tricky one party will always be inconvenienced. I once worked with a company in Arkansas and was living in Irkutsk, Russia, a fifteen hour time difference. We had our daily meetings at 9:00am CDT and 12:00am for me in Irkutsk. That was a bit one sided. I would not recommend that for teams, at least not on a permanent basis. It could be that way for a week or two weeks and then switch to something like 7:00am CDT and 10:00pm Irkutsk time. At least move it around a bit to not inconvenience one side all of the time.
- I do not want to talk in real time. Believe it or not there are people who do not like to talk in real time. They would prefer to receive an email and then think about it and then respond. On one hand this is understandable especially when there are differences in native languages. However, no matter what the asynch communication of email or posting messages in a collaboration tool still takes more time than synchronous communication. Depending on the project being undertaken or the phase of the project, nothing can replace real time communications.
In short though, no matter what the situation, nothing can take the place of real time communication. If you are wondering what may be going wrong with your project. Start talking every day and digging in to what is happening; you will be on your way to a more successful project.