On the domestic front and in my view, unless we are able to create smart monitoring devices that cost say Ksh 100, it is going to be a very difficult sell to the consumer. Even if the hardware monitor is sms or data based, somehow we would need to find a way to provide an incentive to the consumer to buy such a unit and maintain its continuity. That places a monitoring project at least 10 years away from now. In the interim, we may need to work very closely with how we can take the consumer away from investing in anything. There are microprocessors that we can design use off in the Ksh 100 device but how wil the data be transmitted from such a device to a monitoring system? I think Scada used by KPLC may not be a solution, as it is so easy for them to actively monitor their own network at very minimal investment costs but this distribution network is out of public reach, especially for people like us. Our work on any design is very limited to a consumer premises which itself maybe a challenge. If public buildings charge ISPs for bring internet connectivity to the building rather than that the internet is a critical and essential service such as a Telco bringing in pstn lines, then you can imagine the hurdles in getting everyone involved at monitoring power outages
If all you're looking for is to identify power outages what's wrong with using any Internet connected PC to monitor its own power status? The basic idea would be that I register on a website and download/run-in-browser a piece of software that sends a heartbeat message every so often (once a minute would be fine). If you get skipped heartbeats it's the case that the (1) machine died (due to a power cut), (2) was turned off (due to user request or in response to a power cut) or (3) Internet connectivity was interrupted. Location placement may be achieved via Geolocation.
(1) may be easily inferred by having the client software register a shutdown event handler, (2) is trickier but I suspect if you had it pop up a dialog box on shutdown asking for the reason for shutdown you'd get some reasonable data and (3) is easily mitigated by using a monotonically increasing periodic counter whose value is sent with the heartbeat and that continues to tick in absence of connectivity.
If you're not particularly interested in real-time information you can simplify this base design even further; just have the software run in the background ticking along periodically and uploading the log whenever connectivity is established. You can then easily distinguish between power cut based and user request based shutdowns by correlating inputs from co-located users. You may further insulate against transient/unidentified error or malicious tampering by basing your power-availability model on a statistical commixture of all input received.
While this solution doesn't address the brown-out or oversupply issues previously mentioned it gets you approximately 50% of the way there with zero capital expenditure on client hardware design and very little on software (both on the client and server side). Furthermore, with this approach the barrier to entry is very low which means you're more likely to get people downloading and installing it.
It's a good idea and one that has the potential to make an impact if executed well. Best of luck realizing it.