Archive for the ‘Business’ Category
We often receive RFPs (Request for Proposals) that demand a firm committed five year product roadmap. Similarly we are often criticized for not having such a “golden” roadmap when other competing products have. Having now worked in an Agile world for some time now, these requests seem stranger and stranger.
The quibble here isn’t with having a plan, it’s with the inflexibility these requests imply. That a company needs to set its course for five years and then any change in that plan is somehow a failure to deliver. That as knowledge and circumstances change that you need to stick to the plan and not adapt to the new situation.
Products are now introduced in “Internet” time. This means they are updated far more frequently (sometimes several times a day). All companies are looking to be “disruptive” and to “redefine” their market. Under these fast moving and fast changing conditions does it make sense to have a fixed long term roadmap?
On the other hand a product needs direction. A product needs long term thinking. You need to decide when to do something quick and dirty versus laying more groundwork and infrastructure to support future features. Stakeholders need to have an idea where a product is developing and what might be coming down the road.
There are quite a few types of roadmaps, there are technology roadmaps, feature roadmaps, release roadmaps, stop list roadmaps, marketing, strategy and many others. This articles generally applies to any of these.
Waste Not, Want Not
One of the key tenants of Agile Development is to reduce and if possible eliminate waste. Waste is any extra work that is being performed by team mates that doesn’t directly add value during the agile sprints. One main source of waste is doing too much and too detailed estimating. If you want a team to commit to estimates then they have to spend a lot of time working through those estimates so that they have the necessary precision. However when you do this, this work is often just waste, since then the work isn’t done due to changing priorities or another team does the work and insists on repeating the process or the project is postponed and when its resumed things have changed.
Roadmaps tend to generate a lot of wasted work. Once a company wants a roadmap that everyone is committed to, then far too much time will have been spent working on the estimates. The trick here is to be willing to accept inaccurate estimates. Many studies have shown that inaccurate WAG (Wild-Ass Guesses) type estimates aren’t really any less accurate than carefully constructed ones. All you need to know for building a roadmap is the order of magnitude of an item, not the details.
Detailed estimates are only done when the stories are going to be performed by the agile team. This work usually happens as a part of backlog grooming in the sprint before the work is actually going to be done. This then ensures that the stories are properly broken down and that the work can fit into one sprint.
Accept the Roadmap as a Guideline
The best way to think of a roadmap is as a guideline for current thinking. It is a mechanism to elicit feedback which can then be used to produce a better roadmap. Publishing a roadmap as a “fait accompli” doesn’t serve nearly as well as using a roadmap as a starting point for a conversation.
Often getting customer feedback on direction without providing any context or ideas is quite difficult because customers don’t spend their time thinking about how you need to develop your product. With a roadmap they can see how your product will fit in (or not) with their future business directions. Then they can provide useful feedback on what will be useful, what will be irrelevant and what will actually be harmful.
Keep in mind that conversations are two way things and the only way to be successful is to incorporate the feedback received and to show that the time spent by the customer talking to you is worthwhile. Corporations that can incorporate and synthesize the feedback from hundreds of customers in an effective manner tend to be the companies that really shine.
Accept that Agile Works
A lot of times the push for a fixed roadmap is a result of the organization outside of R&D not being comfortable with the Agile idea of working on the most important story all the time. They liked the old days where a giant requirements document was produced and upper level management reviewed this and then felt comfortable that they could let R&D go off for a year or two to work on this without paying any more attention.
Generally it’s proven out that Agile is much more efficient and produces better products that meet customers’ needs much better than the old waterfall execute the requirements approach. But if upper management wants to know what R&D is doing they have to pay attention since things are fluid and always changing. This can be hard to accept, but now its being found that Agile can be applied to other parts of the organization and rather than older parts of the company dragging down the Agile parts, now all departments are going to Agile and its working very well for modern companies. In fact many people now believe that if a company doesn’t make this transition then it will become less and less competitive. The sad part is that Agile produces far better artifacts showing the progress of a project, you just need to learn how to use the tracking software to see them (another wastage is producing specialized reports just for upper management consumption).
In the end, the goal is to be as customer connected as possible. Always working on the item in the product backlog with the highest value for the customer. This is now a proven principle for success. Dictating to customers what is good for them will just alienate your customers and send them elsewhere.
Creating a general roadmap that is used to get customer feedback and buy-in is just one tool of many to being a better customer connected company. And again the key secret ingredient is always adapting to change and not becoming fixed in your direction.
Of course when talking to customers and often other stakeholders, they will start out with how they need everything yesterday. But you have to steer the conversation to choosing priorities and not being brow-beaten into accepting that any estimates need to be shorter.
Roadmaps are great tools for having a conversation with stakeholders on the direction of a product. You just have to be careful not to fall into the trap that the roadmap is somehow a commitment that can never change. If done properly it can serve quite a few goals that are fully compatible with an Agile methodology.
If you are presenting a roadmap at a conference or WebEx, always prefix the presentation with that this is our current thinking and that we are always looking for feedback and ways to make the roadmap better.
We are just rolling out Sage 300 2016 which includes Web versions of Common Services, Bank Services, Tax Services, General Ledger, Accounts Receivables and Accounts Payables. The focus of this release isn’t on a new flashy portal with flashy KPIs (although we do have those) or other new technology enabled functionality. The focus is on the core Financial Accounting functionality; on entering financial accounting documents into the system and providing the key reports that go along with these.
This is the first of a series of releases that will translate the Sage 300 product line to a new Web based technology platform. It will move all the functionality of Sage 300 to this platform and use this new platform to add newer technologies and functionality.
This article is meant to give a quick overview and flavor for what you will see in our new Web UIs.
A lot of Common Services are screens that enable functionality through the rest of the product. For instance the Optional Fields setup UI is present and is used to configure Optional Fields that then appear in so many other places. There are the usual basic common setup UIs for Company Profile and Calendar Services.
Bank Services is a part of Common Services and it provides a centralized place to manage your bank accounts. Reconcile bank statements and enter various bank related items like service charges. It also provides a common check printing UI for other applications to use when printing checks.
Tax Services is another part of Common Services that lets you configure your sales taxes in a single place and then they are used everywhere that involves sales taxes. You will see the full tax services support though out many Web UIs.
Sage Payment Solutions (SPS) is also configured from Common Services. We fully support Sage Payment Services for taking credit cards in A/R as part of this first release. We integrate to the Web versions of the SPS screens to take and process credit cards. As before no credit card information is stored in the Sage 300 database, its all handled by the SPS screens and saved in the SPS vault.
Although they aren’t supported by their own screens there is a lot of common functionality that goes across all the modules like Import/Export, Finders and processing custom Crystal reports. These are all present in the new Web UIs as well.
All these screens fully support multi-currency and fully honor Sage 300 security.
This module offers all the standard G/L screens. From here you can define your G/L Account structure, create and maintain your G/L Accounts and enter your G/L Journal Entries. Generally everything is G/L is based on fiscal year and period (which we provide a specialized control to enter) and allows you to follow GAAP rules exactly.
Here you have all the screens to setup and maintain you’re A/R sub-ledger. You have screens to enter and maintain Customers. There are the main document entry screens of Invoice Entry and Receipt Entry. There is integration to SPS for credit card transactions. There is retainage accounting, optional fields, sales tax calculations and all the rich functionality you are used to.
Here you have all the screens to setup and maintain you’re A/P sub-ledger. You have screens to enter and maintain Vendors. There are the main document entry screens of Invoice Entry and Payment Entry. You can track vendor account and transaction details on screen and on printed reports. Accounts Payable produces the reports you need to avoid late payment charges, secure vendor discounts, and match cash requirements to cash resources. There is tight integration to Bank for printing and tracking checks.
Hopefully you will try out our new Web technology for the Sage 300 UIs. This moves Sage 300 to a fully supported technology platform that continues to evolve quickly. This first release offers lots of functionality across all of Financial Accounting with new releases coming quickly to provide the rest.
If you remember our last UI transition from CA-Realizer to VB6, you will see that this one is happening at a much quicker pace.
Since the Business Logic is still the same as the existing product, you know that this is a very full featured and robust set of accounting functionality that has been in use at a great many companies for quite a few years now.
For more information check out the online help at: http://help.sage300.com.
Sage 300 2016 has now been “Released to Manufacturing”. This is a bit of an archaic term since we don’t manufacture anything anymore. It really means that R&D has handed the product over to the next step in the chain that will allow it to be installed at customer locations. This is a staged plan where it first goes to “controlled release” customers and then out to the wider audience in phases. The important thing is that the software is ready for customers to go live with in production environments.
Recently I’ve blogged quite a bit on the new Web UIs, but in this article we cover all areas of the product.
The marquee feature is of course the new Web UIs. You can now run Common Services, General Ledger, Accounts Payable and Accounts Receivable from Internet Explorer, Edge, Chrome, Safari or Firefox. There is a nice Home Page with KPIs, good international support and many usability enhancements. You can now easily access Sage 300 from a Mac, Linux computer or tablet.
You no longer need to run Day End, post outstanding batches or complete bank reconciliation before upgrading. This should make it much easier to schedule when you perform the upgrade as you no longer need to sync with these other ongoing processes.
We now run regacc.exe during installation (full and workstation setup), so that you don’t need to do this as a separate step if you want your users to run with lower permissions (more on that later). This is also run during un-installation to clean up the registry.
Better UAC Support
The goal of this support is that regular users can run day to day without requiring power user or administrator rights and that they can leave User Account Control (UAC) turned on. This means that there won’t be any registering of controls as the user runs (this is all done at installation time) and we’ve moved where we store things in the registry so a regular user won’t be required to write to HKEY_LOCAL_MACHINE. Of course to install the software you still need to be Administrator and the usual procedures still apply.
Support Newer Microsoft Products
With this release we add support for Windows 10, Office 2016 and SQL Server 2016.
Note that we no longer support Pervasive.SQL or Oracle. Further we only support Windows 7 (SP1), Windows 8.1 and Windows 10. I.e. we do not support Windows Vista or Windows 8. We also only support the 64 bit versions of the operation systems, we no longer support the 32 bit versions.
Check the system requirements KB article for all the gory details.
This release includes Payroll 7.2 (which is also available for Sage 300 2012 and 2014). For US Payroll this includes cost center overrides and ACA reporting. For Canadian Payroll it includes the PIER balancing report and the T4A/R2 Report.
- The G/L Transaction Listing Report can now be run either by document date or by posting date.
- G/L Journal Entry has an “Entered by” field.
- A post button was added to the main document entry screens like G/L Journal Entry so you don’t need to go to the batch list to post the batch.
- The tax tracking report can now be from/to a fiscal year/period.
- The Tax Clear History function has been moved out of the Tax Tracking report and into a separate periodic processing function.
With every release we update the various integrations that are included with the product. Make sure you also update these integrations like Sage CRM 7.3 to get all the benefits from that update as well.
Lots of new things in Sage 300 2016. Especially check out the new Web UIs. Besides the features mentioned there are always lots of bug fixes and minor improvement under the covers that improve the stability and performance of the product.
Sage 300 has always been an international product that is used in many countries around the world. This includes releasing the product in multiple languages, supporting multi-currency, supporting regional settings for things like dates and having flexible configurations for things like sales taxes. As part of the new Web UIs we’ve also carried through all these features into the world of the Web browser. This article describes how some this works, since the browser is a bit different than setting regional settings in Windows.
Generally if you are in a given location, all your computers and users will all be set to use the correct location, so there is nothing for you to do. But if you do want to change things, need to troubleshoot a problem or experiment then these details could be helpful.
Languages and Locales
In the desktop version of Sage 300 you set the language used with the Sage 300 User. Then when you log in as that user, Sage 300 will load the appropriate language files for that user and display in that language. For things like date formats, the desktop product will get them from the Windows regional settings (i.e. the registry) and use that format. In the browser you select a combined language region locale code which determines both the language and the regional settings (like date format). Below is a table for some of these. For the complete list, check out this website.
|Sage 300 Language Code||Browser Locale Code||Description|
|en-AU||English (Australia) (date format dd/mm/yy)|
|en-US||English (US) (date format mm/dd/yy)|
|ESN||es||Spanish (not support in Web UIs until Feb release)|
I didn’t include South Africa which is en-ZA because the date format for that is yyyy/mm/dd. When I Googled en-ZA, all I got was complaints that it should be dd/mm/yy. So if you are South African and like yyyy/mm/dd as your date format then by all means select en-ZA. However is you prefer dd/mm/yy then you might want to pretend you are Australian and select en-AU. We won’t change our English as a result, so hopefully we can avoid any conflicts about shrimp on the braai vs barbie.
You can set this for any of the Browsers by going into their settings and adding languages and setting which is the current one. For Chrome and Firefox there is a really handy add-on that puts the list in a convenient menu at the top so you can easily toggle between these. In Chrome this is the “Quick Language Switcher”. In Firefox this is the “Quick Locale Switcher”.
Below is G/L Journal Entry in various languages and date formats. Note that data in the database is not translated, which is why there is English text in some of the data fields.
Configuring the Business Logic
Using the Browser settings affects most things, but some language strings and locale settings come from the Business Logic layer. The Business Logic does get some of its settings from Windows, so to get these in sync with the Browser you should set the Sage 300 application pool in IIS to run as a user that is set to the regional settings that you wish. You also have to change the user that the Sage.CNA.WindowsService Service runs under. By default the application pool and the Sage.CNA.WindowsService service will run as “Local System” which works, but has a few problems:
- Local system is very high in security settings, so it’s safer to set this to be a regular user (we don’t require admin rights).
- Local system can’t access network resources, so if the shared data folder is on another server you need to change this to a user that can access the shared data folder.
- It’s easier to login as a regular user and set their settings to what you need.
You should also ensure that the Sage 300 User has the correct language set since any messages generated by the Business Logic will be in the language of the Sage 300 User.
Most people will still be using the VB screens either due to customizations or modules that we haven’t moved to the web yet. Generally if the Browser, Windows users and Sage 300 users are all set to the same thing then you will get consistent languages and regional settings across everything.
As Sage 300 moves into the Browser we want to move our international heritage as well. In the web world there is much better support for many of these things and you will see this in our new Web screens.
As part of developing all the Web Screens for our upcoming Sage 300 2016 release, we worked with quite a few contractors at Sonata in Bengaluru, India. I originally visited them back in November 2014 and wrote a series of three blog articles on my experiences over there (part 1, part 2 and part 3). I then visited them again in March 2015, but didn’t blog about that visit. Now I’m in Bengaluru again and thought I’d add another posting to the series.
One change is that I’m going to try to use the proper name of the city which is now Bengaluru and not Bangalore. The name was changed just days before my first visit and was a bit confusing.
The Story of Sage 300c
We started the Sage 300c project two years ago, built on a lot of the ideas and architecture from the previous Orion project. We brought in Sonata for their expertise in Microsoft ASP.Net MVC technology which we adopted for the new Web UIs. We started work collaborating with a small team from Sonata to produce a proof of concept where we produced fully working A/P Vendors and A/P Invoice Entry screens. We chose these as reasonably complex but not so complex they would take too long to develop. We learnt a lot from this POC and used that to build a frame work for our new UIs. We then built up the team and proceeded to build the G/L screens. This was a test of building a full application to get a better idea of the work and time that would be involved when we ramped up for the whole project. This went quite well and we ramped up the team and started work on A/R, A/P, Bank, Tax and C/S. We then decided to accelerate the project and ramped up the team in Bengaluru again to simultaneously work on I/C, O/E and P/O. I blogged a bit about this process on how to organize Agile development and how to scale Agile development.
We are now code complete on Sage 300 2016 and just finishing final regression ready for release. The I/C, O/E and P/O screens are coming together nicely ready for our February Product Update. Any large software development project takes lots of hard work, many long hours and some heroic troubleshooting. This project was no different. Looking back now its amazing how much commitment to producing a first class quality product went into all the work. All the Agile Scrum teams around the world really took their work seriously and really made the effort to produce something everyone could be proud of.
Team Wrap Up
With this visit we’re wrapping up the giant accelerated project, and with the main Accounting modules completed we’re proceeding on a smaller scale. It’s interesting to see this transition while in Bengaluru at Sonata. The skills used on this project are in high demand and everyone moving off this project has a place on a new project. People are excited to both complete this project and to start their new project. Overall Sonata is expanding with a new building opening next door, next month.
This Sonata office is located in the Global Village Tech Park. There are a lot of large companies similar to Sonata located here. It is really remarkable how all these companies are continually managing ramping up and winding down so many large projects with so many people involved.
Further there are 2.97 million IT professionals in India and 35% of them are located in the Bengaluru area. This means the out of the total population of 8.52 million, 1,039,500 are IT professionals (i.e. programmers). This is an amazing number of computer pros and what is helping drive Bengaluru’s annual growth rate of 38% which has propelled it to become India’s fourth largest city.
As I leave Bengaluru, on one hand its sad to say good bye to so many people I’ve worked with over the last two years, on the other hand its exciting that they are all moving on to other projects. Hopefully I’ll run into them again in a future visit. Meanwhile with the core Accounting screens completed, Sage 300c has a solid Web technology base and can move on to really adding to the base we’ve created.
P.S.: Plus the people I was working with took me to Bannerghatta National Park where we went on a Safari and saw lots of tigers, bears, lions and elephants.
Over the last little while we’ve lost some people to startups and we’ve hired a number of people away from startups, so what factors are causing this movement? Desire for greater autonomy and more flexibility? Or is it today’s version of a Klondike gold rush where hordes set out on the treacherous journey but few strike it rich?
I’ve spent most of my career with the Sage 300 product whether at Computer Associates or Sage, both of which are well established companies. Previous to that I worked for a number of startups as well as tried working as a consultant. All of these were great experiences and all provided great learning opportunities.
When considering a startup, there are two options: one is to create your own startup, where you have a great idea and want to take it to market and the other is to join someone else’s startup as an employee. In this blog we’re considering joining someone else’s startup. Quitting your job and creating your own startup is a whole other topic that I may address in a future blog.
Some of the people working at Sage started at Basic Software Group that originally developed Accpac. They were eventually were acquired by Computer Associates and later by Sage. This was a successful startup where the original team members did quite well. Many people at Sage are here due to the acquisition of their startup. So joining a startup at its inception, you may eventually have the choice of remaining at a (now) established company or moving on to the next startup or a spin-off of the established company.
I blogged a bit about how work environments are changing here. How startups are often located downtown in shared spaces or incubators, whereas established companies tend to have larger building out in the suburbs. The established companies are working to modernize their office environments but tend to not quite go as far as the startups. Many established companies are moving their R&D centers downtown to attract younger talent. When you interview with an employer make sure you check out their work environment so you won’t be surprised on the first day at work.
The picture below is from a startup incubator where a number of companies share the space. Chances are each table is a different startup!
Generally, if you work for a more established company you will get a salary which is paid regularly and reliably. This also tends to be the main part of you compensation, with a number of other standard benefits like medical, dental and retirement matching. Stock options and stock grants tend to be quite rare these days.
However; if you work at a startup, you get a much lower salary and fewer benefits. What you get in return are stock options or stocks. These give you ownership in your company and the chance to cash in if things are successful. The danger is that if the company goes bust (which over 90% do) then these are worth nothing. What everyone is looking for is that magical IPO or a buyout by Google where suddenly everyone is a millionaire. Another thing to watch out for is that if things drag on, each round of fund-raising dilutes the equity of all existing shareholders. So often at the end of several rounds of fund-raising and venture capital, those original generous stocks and options aren’t worth nearly as much.
People at startups tend to get very nervous as to whether they will receive their next round of funding or not. They are usually entirely dependent on outside sources to keep going. They usually have no revenue coming in from their products under development. If the outside sources get nervous, lose patience or switch interests, then the company can suddenly be without any money.
If you have (or want) a mortgage, managing this from a startup can be very challenging. Similarly, if you have children and need to support your family, you have to consider if you can afford to miss a couple of paychecks when things are tight. Often this can be a deciding factor of working at a startup or not.
Joining a startup can be difficult because you will have a very steep learning curve without much support. You will also need to learn a lot of things outside your direct expertise. The team will be smaller and everyone will need to take a larger role.
Established companies will have more formal programs to bring you up to speed. A lot of times the work is more specialized although you can move around.
If you are looking to learn a lot, then startups provide great educational environments for this. Sometimes you may learn things you don’t want to learn like managing bankruptcy, but it’s all learning nevertheless.
Within startups you have a lot more responsibility. The team will be small and everyone is relied upon to play a major part. Long hours will be required. Chances are you will be working directly with the CEO.
At more established companies there are better defined management structures and larger teams so the responsibility is more spread out and there are more resources to back you up.
Some people thrive in one environment, others in the other. Which company model is right for you depends upon your level of comfort and how you like to work.
To some degree choosing between an established company and a startup is choosing the get rich slowly, a strategy expounded by David Chilton in The Wealthy Barber or Thomas J. Stanley and William D. Danko in The Millionaire Next Door. Which is basically to save percentage of what you earn every paycheck and invest it over time. Versus the startup approach of betting on a long shot and then working your guts out to make it succeed. The truth is that the first approach will always work whereas the second approach is very risky. Of course, you can do a composite and try a couple of long shots and then go for the sure thing.
This is part 3 of my travel blog on my current business trip to Bangalore, India. The two previous parts are here and here. In this article I want to talk about the various communications challenges we have in working with globally dispersed teams and in particular with the one here in Bangalore.
The main purpose of my visit to Bangalore has been to enhance communications. To meet all the people I regularly talk to on the phone or exchange e-mails with. I’ve met several team members you have spent time in Vancouver already, so this has been my turn. Meeting face to face certainly provides the best medium for communications. Face to face is the most reliable mechanism, especially when you can discuss things over a period of time (in this case I had two weeks). But the trip to India is quite grueling and it’s a long way from home. So practically speaking we need other ways to enhance communications for the rest of the time. A key part of face to face visits is to learn who knows what, so in the future people know who to talk to.
One of the big reasons for this trip was to solve a number of lingering problems that just didn’t seem to be getting solved. We would think decisions were made and then a few status calls down the road they would resurface as open again. Generally it appeared communications between the various teams on this project were facing some serious challenges. Most of the discussion in this posting isn’t specific to these particular teams or to teams in India. They could equally apply to teams in different cities in North America, or even sometimes teams on different floors of the same building. But since I’m writing this in Hong Kong airport on my return from Bangalore, some of the items might have an Indian flavor to them. I talked about some of these issues in my blog posting on the umbrella ceiling which was to do with working remotely, but I think this topic deserves more discussion.
Roots of the Problem
I think the biggest root of this problem is that either people are trained that its best to be self-sufficient and try far too hard to solve things themselves rather than ask for help or people just don’t realize that there is someone else who knows the answer that they can ask.
Another cause might be politics between different companies when the teams work for different companies and there is some higher level interference because management wants things to look better than they really are. The paradox here is that if the team did ask for help, then things would be able to get better. By not asking for help, maybe you can create a short term perception of super-human ability, but this then just falls apart when the first milestone is missed.
Similar to the last paragraph, project time pressure also leads to a certain amount of bad decision making in this regard. Programmers under the gun will just work on their short term deliverables with all their effort and ignore e-mails, not read Wikis, etc. Doing this saves a bit of time in the day, but costs dearly if a key piece of information was communicated but not received.
Technology is Not the Answer
There are all sorts of great technologies to enhance communications. Video phones like Skype, all sorts of IM clients, very fancy telepresence setups, Wikis, blogs, etc. People are almost always connected these days to the Internet, so even with terrible time zone differences like between North America and India, communication can still be fairly immediate. But this all depends on people actually using the tools. A lot of times people see all these tools as a distraction and tend to avoid them.
The really hard problem here is how to disseminate important information that people will pay attention to. If there is too much information, then it’s just treated as spam and ignored. If there is too little then there are communication problems or people don’t bother checking for it. Add to this the problem that usually a new piece of information needs to be communicated three times in order to be absorbed.
Most Programmers are Introverts
Independent of where a programmer lives or works, whether it’s Canada, South America, India, Asia or where ever, there is a pretty good chance that programmer is an introvert. This usually means that the programmer almost has a physical repulsion to picking up a phone and calling someone. This usually means that the programmer is not going to arrange a telepresence session on their own initiative. This usually means the programmer won’t arrange a remote desktop session to work with someone to solve a problem.
Using e-Mail to Delay Communicating
E-Mail is often used as a way of delaying communications, especially when different time zones are involved. A good way to put off communications is to just send an e-mail. Often you won’t have to deal with the answer until tomorrow. It’s common to see a question e-mailed one day, then the next get a response asking for clarifications, then send the clarifications, then the next day get back an answer to the wrong question, then send further clarifications, etc, so that a simple question takes a week to get answered even though people are being fairly prompt with responding to e-mails.
E-mail is also a continuous interruption. Managing how you answer and manage your e-mails can be a big productivity booster. Certainly turn off audible alerts when you receive e-mails and don’t let them ruin your concentration on your real job. Perhaps set aside specific time slots for answering e-mails.
Special Problems to India
People often list language as a problem when speaking to India. One thing to keep in mind is that India actually has 1,652 languages. Even in Bangalore where the common local language is Kannada, many people working in the high tech industry have migrated from other regions of India. This means that often the only language in common between team members in India is, in fact, English.
Development groups in India tend to be quite large. Often communication problems aren’t limited to overseas. Often you get worse problems communicating things just to the whole team at the India location or just connecting the right people together who in reality sit quite close together.
Of course there is the 13½ hour time zone difference, and then the fact that it’s such a long flight to get to India. Visiting has gotten easier over the years, but it can still be challenging for westerners.
Communications is always a challenge on any large project. As a project increases in size, the number of communication channels increases exponentially. Enabling effective communications on a large project can be helped by technology, but is really a people problem and has to be continuously managed.
And so concludes my blogs while on my Bangalore trip. Perhaps not a true travel blog, but I like to blog on the issues I’m dealing with and this trip provided some good topics. Anyway I’m back in Vancouver now and life returns to normal.